[plamzi]

You could look into threading for any processes that don't need to feed back into the main loop at all or do so infrequently. Any task that can be delegated fully and whose outcome doesn't have to be 'synced up' at all is a very good candidate for threading. For instance, saving the player stats / config to a database / file. If you implement that, then in theory you can save stats / configs more often and for more players without slowing the main game thread.

Loading stuff up into the memory can also be threaded but it can be considerably trickier. I imagine you'd have to set some kind of a wait state on the socket that requested something to be loaded from db/disk and only service it when the data is ready. You'd have to remember what unique data this particular socket is waiting to receive from the loading thread. A good example is when a player first enters the game.

I haven't done either threaded saving or loading myself but I'd start with saving. In weighing the pros and cons to either, keep in mind that spinning off and managing threads is itself costly. If you have to do it too often, it may defeat its purpose and actually worsen overall performance.

Perhaps someone with practical experience in threading will pitch in with more/better advice.