[crossfire] Map cache

[Mark Wedel]

  Catching up on various points:

  I have no plans, no do I expect to see any work on making crossfire multi 
server distributed.  The work to do that would be huge.  At minimum, the game 
almost needs to be thread safe, so why not just do that?  With multi thread/core 
processors hitting the market soon, it makes more sense (sun's 32 thread cpu 
will be out sometime soon for example).

For item stacking, since the issue here is related to performance, it would be 
raw number of items that don't merge.  This may be hokey, but the goal here is 
to improve efficiency by reducing number of objects on the space, so we don't 
care actual nrof, weight, volume, whatever.  We just care if the number of 
objects is above X, objects should spill over.  This also helps out on the 
client interface aspect.

  Putting objects into misc containers adds a bunch of complication and not sure 
it really helps out.  If another axe is dropped, then presumably you have to 
check all the objects in the 'axe container' to see if it merges with anything, 
so loose any efficiency by having fewer objects.  Also, having that pseudo 
container would seem to result in other oddities, like special handling when 
player tries to pick it up, etc.

  In terms of trying to do actual threading:
You can of course set up locks.  I believe the loader is inherently unthreadable 
(do to lex), so you'd need a global lock to prevent that happening.

Each player structure would need a lock, so things like chat, talks, shouts, 
etc, could be handled safely.

Otherwise, my thought is to basically move away from global objects and instead 
put the object link list in the map structure.  Thus, loading and saving doesn't 
need to touch any global structures, and even for processing, each map could be 
its own thread.  But as previously said, a lot of the functions are not thread 
safe, so would either need locks or need to be made thread safe.

  As far as what started this discussion - actual map load times:
I haven't profiled it, but a few guesses:
1) Loading is lex, but still lots of strcmps and the like.  So that isn't as 
fast as say a binary system, but not easy to fix that.

2) objects with huge number of spaces isn't efficient - that is because for each 
object loaded on the same space, it has to compare with all the other objects on 
the space to see if any merge.  Thus, it becomes an O(n^2) operation.  Fixing 
that is a bit more difficult, but if the number of objects allowed on a space is 
limited to some value, that helps out (note same thing happesn for chests or 
players inventory however - those are harder to fix).