Kids, It's Optimization Time!Holger Weissböck on December 16, 2013
Hello floxxers! Let me tell you a story: we usually ban everything we want to do, need to do, can’t do right now and all ideas that spark through our heads onto long lists of work items. These lists get sorted, reviewed, reduced, distilled and sometimes forgotten. ;-) Not this time, however:
Over the past few weeks we finally had the chance to work through our list of possible server-side optimizations. These items included amongst other things faster serialization, smarter caching, general performance tuning and a more intelligent way of handling and storing entities.
“What do I care?”, you ask. Well, these changes made it possible for us to make entity and player operations much more affordable. Read on…
Up until now storing an entity had a base cost of
4 + 2*n operations, where n is the number of indexed properties on the specific entity. This was pretty much the biggest outlier in our pricing scheme. The reason for this being a outlier is that storing stuff usually has the downside that there’s hardly any way to cache or delay it. Everything has to be updated immediately.
However, given the sum of optimizations from above we were able to reduce the costs for storing entities to
2 + 2*n operations. For most of you this pretty much cuts the melon of entity modification costs in half!
Up until now the op costs for querying for player/entity IDs were calculated as
1 + offset + 1 per result. Right now, and mostly thanks to a new caching layer, we are able to reduce the costs for entity/player queries down to a simple
1. At last queries are where they should be!
By the way, that squirrel is caching nuts. Get it? Get it?
I am extremely happy that we finally got around to implementing most of the optimizations that were lingering around on our todo list for so long. Finally, and mostly for show, here are again the changes compared in two fine diagrams:
I think this a pretty neat christmas present! What do you think?