[MUD-Dev] Re: TECH: Distributed Muds

[Chris Gray]

> From: Vincent Archer <archer at nevrax.com>

> A friend looked at what we were trying to do and said: "it's a
> trap".  Because you no longer know that objects are now in fact
> stored on disk, and not resident in a process memory, you quickly
> fall into traps. Like searching for an object by scanning a linked
> list. Ahhh, but the linked list will quickly pull 1Gbyte of data in
> your process just to find the object that has this property or
> that. And worse: you're not conceptually aware of it. Until you try
> the program on the real data, and finds out everything crawling at
> speeds that would make an old 8086 seem a decent system :)

That only happens if you have such large linked lists. I've seen
discussion here in the last month or two about having global lists
containing all of the objects in the world. I've never been really
sure why you need such a thing in the first place. Limit yourself to
local lists, like the list of objects in room X. Then, the scanning is
no big deal, since you likely had to bring all of those objects into
memory in order to show them to the player.

If the MUD programmers are aware from the start that the system is
running as a cache for a persistent store, then they can readily find
solutions to problems that don't require the entire database to ever
be scanned.  Sometimes it can be convenient to have such powerful
facilities available to a few chosen programmers (e.g. to find objects
that the system has lost), but hopefully they are smart enough to
minimize their use of them, and to keep such use to off-peak times.

--
Don't design inefficiency in - it'll happen in the implementation.

Chris Gray     cg at ami-cg.GraySage.COM
               http://www.GraySage.COM/cg/
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev