"Erwin S. Andreasen" <erwin@pip.dknet.dk> writes:
> Rather than wasting memory on mostly unused static buffers and
> implementing such a multiple-buffer solution in each function returning a
> pointer to static storage, consider implementing a general solution. The
> idea was first introduced by Oliver Jowett in his IMC code: a pool of
> static storage that functions with need for static storage request from.
> The code looks like this:
Certainly; there are many better ways to handle the problem. I don't
know how much I like the imc code (going by what you say here; I've
never actually seen it). But allocating on the heap would probably be
better.
On a related note...
I mentioned about a week ago about experimenting with a garbage
collecter in circle. So far my experiences have been _VERY_
positive. Memory use is up, slightly, from before, but only by about
15%. Yes, that's a large chunk, and I can't say for sure how it will
behave with a larger test base (right now my mud is building only with
minimal code testing). However, the memory use is bounded. Memory
leaks are much harder to have occur. Boehm's garbage collector is a
VERY nice program. In this example, it would just return a buffer
allocated via GC_malloc. You never have to free it -- the garbage
collector does that automatically when there are no longer any
references to the memory. Basically, you never have to call free :)
I was very surprised to see garbage collecting working this well in a
C environment. If anyone else is interested in using it in Circle,
send me a note or post here. It's definitely worth it IMO.
> Oh, another note, regarding some argument-splitting code someone - James
> Turner I think - posted. It's one thing to use global variables for things
> like a list of players or rooms in the game - but using a set of global
> variables for the return value of a function is a IMHO bad idea.
> Especially a function used for splitting arguments up - that is a thing
> very common to MUD code.
I agree, it is messy. But it works for its purpose -- splitting
arguments to commands. It could easily be extended to not have the
problem above; if such a need occurs in my codebase I'll definitely do
it. But so far it hasn't been necessary.
> PS: Regarding discussion for ASCII vs binary pfiles: I have never heard
> any developers of any MERC 2 derived MUDs (the version which introduced
> ASCII pfiles) nor its many derivatives consider binary pfiles. I have
> never heard anyone complaint how long players took to save or load. Maybe
> in 1992 people complained how MERC took up 20% of their 386'er running
> Coherent but by now, whatever extra time saving ASCII files takes is worth
> less than the programmer time saved because of the extendibility they
> present.
You're right, and I think for the most part, there is a way to reduce
the overhead to manageable levels. But scanning through _each_ ascii
file at reboot just isn't an option. A separate index file for the
most common entries (name, id, last login) would probably be best,
even though it is a hybrid of the two. From what I gathered from one
of Sammy's posts, I think that this is how its done.
But performance _is_ a valid concern, as is proper behavior in a
cooperative environment.
> PPS: If I used binary pfiles on AR, I'd estimate the size of the player
> file to be about 82 megabyte: 6200 pfiles a 14000 bytes - and that'd be
> only if I put artificial limits on may things stored in lists like
> aliases, spell customizations, environment variables etc.
You don't put growable data (aliases, eq) into the flat database; only
strings, integers, and structures of the same. Variable length
entries should be stored in separate files.
--
James Turner turnerjh@xtn.net
http://www.vuse.vanderbilt.edu/~turnerj1/
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/15/00 PST