MUD-Dev
mailing list archive
[ Other Periods
| Other mailing lists
| Search
]
Date:
[ Previous
| Next
]
Thread:
[ Previous
| Next
]
Index:
[ Author
| Date
| Thread
]
[MUD-Dev] Persistant storage.... My current idea.
- To: mud-dev#kanga,nu
- Subject: [MUD-Dev] Persistant storage.... My current idea.
- From: J C Lawrence <claw#under,engr.sgi.com>
- Date: Wed, 22 Apr 1998 16:26:32 -0700
- Delivery-date: Wed Apr 22 16:26:52 1998
- Delivery-date: Wed, 22 Apr 1998 16:26:52 -0700
- Envelope-to: claw#kanga,nu
- Reply-To: mud-dev#kanga,nu
- Sender: "Petidomo List Agent,,,," <petidomo#kanga,nu>
Date: Sat, 4 Apr 1998 21:27:19 -0600
Message-Id: <199804050327.VAA08891#laurel,actlab.utexas.edu>
From: Cynbe ru Taren <cynbe#muq,org>
To: cg#ami-cg,GraySage.Edmonton.AB.CA
Subject: [MUD-Dev] Persistant storage.... My current idea.
cc: claw#under,engr.sgi.com
cg#ami-cg,GraySage.Edmonton.AB.CA (Chris Gray):
| If you keep an index table in memory all the time, then there will also
| be no more than one disk read to get any DB entry.
| [...] After a few header words, index file is an array of small
| structs, containing a 16 bit slot length, a 16 bit 'used' length, and
| a 32 bit file offset.
True, but if ram is cheap, why use disk-basing at all? :)
What's your average object size?
I presume your scheme works well with your design, but with many
systems, statistics show an average object size of 13-16 bytes.
E.g., Smalltalk-78 I believe quoted a value in this range; QwestMUCK
when I was running it was dominated by strings with a similar size;
I'm sure most Lisp system would show similar statistics.
Clearly, if the average object size on disk is 16 bytes, and the
index file is 8 bytes/entry as above and kept in memory, then the
disk db can be at most twice as large as the RAM image, which
isn't a very satisfying space gain for the all the coding effort
involved in implementing diskbasing.
The vm.t module I'm using in Muq currently has an in-ram overhead
of 1 bit per object on disk, which means that a system with the
typical average object size of 16 bytes can support a limiting
db 128x larger than process ram footprint in principle, and probably
a comfortable 10x factor in practice.
(I'm trying to set up Muq as a general-purpose server suitable for
a wide range of applications, so I have to make fairly conservative
design decisions on these sorts of issues. A more tightly targetted
server can of course make different trade-offs.)
Cynbe
--
J C Lawrence Internet: claw#null,net
(Contractor) Internet: coder#ibm,net
---------(*) Internet: claw#under,engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...
--
MUD-Dev: Advancing an unrealised future.
- Thread context:
- Re: [MUD-Dev] Persistant storage.... My current idea., (continued)
- Re: [MUD-Dev] Persistant storage.... My current idea.,
Chris Gray cg#ami-cg,GraySage.Edmonton.AB.CA, Sat 04 Apr 1998, 23:21 GMT
- Re: [MUD-Dev] Persistant storage.... My current idea.,
Chris Gray cg#ami-cg,GraySage.Edmonton.AB.CA, Sat 04 Apr 1998, 23:21 GMT
- [MUD-Dev] Persistant storage.... My current idea.,
J C Lawrence claw#under,engr.sgi.com, Wed 22 Apr 1998, 23:26 GMT
- Re: [MUD-Dev] (fwd) Re: Roleplaying,
J C Lawrence claw#under,engr.sgi.com, Wed 01 Apr 1998, 22:26 GMT
- Re: [MUD-Dev] World Persistence, flat files v/s DB v/s ??,
J C Lawrence claw#under,engr.sgi.com, Wed 01 Apr 1998, 19:41 GMT
- <Possible follow-up(s)>
- Re: [MUD-Dev] World Persistence, flat files v/s DB v/s ??,
J C Lawrence claw#under,engr.sgi.com, Wed 01 Apr 1998, 20:48 GMT
- Re: [MUD-Dev] World Persistence, flat files v/s DB v/s ??,
J C Lawrence claw#under,engr.sgi.com, Wed 01 Apr 1998, 22:28 GMT
[ Other Periods
| Other mailing lists
| Search
]