Last days I've worked on refactoring code and CPU investigations.
Connection.hx modifications to avoid CPU consumption
#if sys
while(!this.isClosed){ //M.E. After 200 reconnections the CPU was gone to 92%
this.ws.process();
Sys.sleep(0.005); // M.E. Avoid CPU consumption by introducing a really small sleep
}
#end
public function close () {
this.isClosed=true; //M.E. add for thread checking
this.ws.close();
}
Perhaps the this._enqueuedSend mechanism can be altered as well to check for the isClosed state?!?! But I'm not sure what the enqueued mechanism needs this...
Running with over more than 200 client initialization tests (and client.closing them) the CPU consumption kept relatively steady.
Now the Windows executable doesn't take much of the CPU.
Remains Javascript that consumes a lot of memory. But this couldn't easily be reproduced on the HaxeKit version, so it might be something related to other parts of HaXe and Stencyl.
I was able to switch rooms on Android, Windows and HTML5 though. I need to test the other targets with the latest build to make sure I didn't break anything for them.
Current state:
- Initialize Colyseus (tested 200x re-initializations)
- Create Room (Lobby, State_Handler) : Also done together with the 200x initializations
- Get room list (getAvailableRooms)
- Join Room
- Leave Room
- Player list
- Send Data
- Receive Data
TODO:
- Investigate Javascript memory consumption
- Publication to all Stencyl targets
- Ping / latency mechanism
- Broadcast investigations
- onAuth investigations
- Different Room Types : RawData,TurnBased,LockData,SimplePhysics,Chat
