31 Jul, 2011, Mastermosley wrote in the 1st comment:
Votes: 0
I was thinking of loading the location data into memory to effectively reduce database queries and writes, what do you guys think about that? Would it eventually create too much overhead with too many rooms?
31 Jul, 2011, Tyche wrote in the 2nd comment:
Votes: 0
I implement a cache that has a configurable size.
New objects are inserted at the head of the cache chain.
When full the oldest objects are dropped out of the cache.

Here's some code.
01 Aug, 2011, oenone wrote in the 3rd comment:
Votes: 0
are the old objects moved to front if they are accessed? if not, you might drop some old objects that are very often used..
01 Aug, 2011, Tyche wrote in the 4th comment:
Votes: 0
oenone said:
are the old objects moved to front if they are accessed? if not, you might drop some old objects that are very often used..

Nope. It's just a dumb cache built on a hash table with link list chains. The width and depth are configurable. It allows specific objects to be marked as non-swappable (I mark my root object as non-swapable and objects attached to files and streams, like connected players). It does keep and track access statistics. So, there's plenty of opportunity for experimentation and measurement. Like perhaps continually moving accessed objects to the head of the chain. Or maybe adding an field that ages the old entries every time a chain is searched and removing ones that reach a certain threshold upon a synchronization. Or perhaps pre-loading likely to be accessed objects (i.e. when a player moves to a new location, preload the objects, exits, mobiles and adjacent locations).

There are some considerations depending on your back-end storage system. It might already be implementing it's own cache. You might be accessing the back-end through another application, which does not/cannot know about modified objects in your servers cache.
02 Aug, 2011, Mastermosley wrote in the 5th comment:
Votes: 0
Interesting, thanks for the post.
0.0/5