Re: [OPTIMIZATION] RAM (previously: Random Thought)

From: Treker (treker@positron.net)
Date: 10/12/00


I don't think it's a good idea to have stock circle use such systems to
reduce memory usage.

This should be a patch or snippet...which it is--and should remain so.  I
think what stock Circle should include are faster, better, speedier
things--not memory-conserving things...of course, in this case you can have
the best of both worlds...

I'll submit some code/more specific ideas when all this schoolwork is done.
-Treker

> -----Original Message-----
> From: Circle Discussion List [mailto:CIRCLE@post.queensu.ca]On Behalf Of
> Fizal
> Sent: Thursday, October 12, 2000 2:33 PM
> To: CIRCLE@post.queensu.ca
> Subject: Re: [CIRCLE] [OPTIMIZATION] RAM (previously: Random Thought)
>
>
> At 12:24 PM -0700 11/10/2000, George Greer wrote:
> >Yeah, that's the one.  It's not the model of beauty or speed but it does
> >what it was intended very well, reduce memory.
>
> Yup, but my changes/additions to your original are also not things of
> beauty. Even after several years of coding, I still consider myself a
> beginner in C/C++. So, if anyone can suggest a better way, I'm
> all ears! :)
>
> 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.
> 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.
>
> 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
>
> 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.
>
> The world I'm using is still stock based. I'm not planning to
> remake it yet
> until I'm finished with a few things first. As to when exactly will that
> be... only God knows. I prefer to be on familiar grounds (literally) when
> testing stuff. 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*
>
> 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*
>
> So, any comments, anyone?
>
> ---
>
> Afizal Mustapa
> Petaling Jaya, Selangor, Malaysia.
> (amustapa@hotmail.com)
>
>
>      +------------------------------------------------------------+
>      | Ensure that you have read the CircleMUD Mailing List FAQ:  |
>      |  http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html  |
>      +------------------------------------------------------------+
>


     +------------------------------------------------------------+
     | 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