On Fri, 13 Oct 2000, Fizal wrote:
>I use 4 files to swap the followings into them:
>- WORLD.BIN: rooms' name, desc and extra desc.
>- MOBILES.BIN: mobs' long desc and extra desc.
>- OBJECTS.BIN: objs' desc, action desc and extra desc.
>- DOCUMENTS.BIN: help files and posts.
>
>Instead of removing all the string ptrs, I actually left some of them there
>for OLC, editting and obj instances. As you mentioned in the patch file, it
>wasn't OLC-friendly.... So, I placed a variable for each string that I
>swapped out to keep track of its location in the file for quick retrieval.
So you're basically keeping an index. Yes, that's a good addition.
>I got the idea from your discussion with Erwin Andreasen that you posted
>to the list long time ago. And yes, I'm keeping the files open until
>shutdown is called.
Profiling the code found it wasn't as awful as he had feared. Doing 10,000
seeks wasn't exactly friendly, but it wasn't slow either.
>When the game needs to access one of the swapped strings, it does:
>
> if (string ptr empty)
> get the appropriate bin file
> go to the location specified by the variable
> read in the length of string to read
> read in the string itself
> return the string
> else return the string in string ptr
If you're keeping a full index, you don't need the length of the string
anymore. You can remove it and keep the trailing NUL for the end of
string. You'll only save 3 bytes per string but that adds up. You may
want the length of the string to pre-malloc() for though.
>When doing a change, especially for OLC, I'll be using the string ptr to
>hold the new string temporarily. Once update is confirmed, I swap it into
>the file and reset the location variable to the position of the new string
>in the file. I left the old string in there since it's troublesome to take
>it out and I figured it doesn't really matter anyway.
As long as you reconstruct after every reboot and keep an index, no it's
not a big deal. In my original code, it would have ended up breaking the
system because it heavily depends on them being in numerical order by rnum.
>[...] Another thing is that I don't really remember why I didn't include
>mobs' and objs' short desc. I remember trying it tho, but then decided to
>take them out again. Hmm.... *scratch head*
They're probably very frequently used. You should've been fine with them
in there with the index though.
>As for extra CPU use, nothing noticeable. Except when doing a where on
>objs/mobs since it tends to do repetitive string retrieval, especially for
>objs. Even then it wasn't as bad as Erwin predicted based on your "quick
>hack". Hey, maybe that's why I decided not to include their short desc at
>the end.... *shrug*
With a complete index, you don't really have to separate them into
different files. The format doesn't care what is in it, after all.
Getting a string from the file with a pre-computed index shouldn't be a lot
slower than using a pointer indirection to get there, assuming it's in the
OS cache. Your overhead would come down to about 2 system calls
(seek+read) which, depending on your operating system, may be well worth
the extra RAM saved.
One idea which would really be neat on a Unix system is to mmap() the data
file. Then you just use a pointer into the mmap() section and your program
acts as if nothing is different from stock (except OLC, which would need to
still only append). The difference to the operating system is that it can
throw away your world strings for memory because the file has a backing
store it can reload as necessary. Your overhead in this case is reduced to
only whatever memory management tricks your operating system has to pull to
map the file. The downside is you might be charged memory (though perhaps
a different sort of memory that isn't limited by the administrator) because
even though the memory is expendable and not really "there", it's still
possibly used.
Maybe I'll make a 'unixwldswp.patch' to play with that idea this
weekend. It's really trivial. :)
--
George Greer
greerga@circlemud.org
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 04/10/01 PDT