Nope! I save player files directly with an 'fp'.  I fork() to save areas for
building. 


> 
> -----Original Message-----
> From: Chris "Winston" Litchfield [mailto:[EMAIL PROTECTED] 
> Sent: Sunday, July 20, 2003 12:57 AM
> Cc: [email protected]
> 
> Jason,
> 
> Did you do a corresponding stwrite_* functions?  This is a 
> great idea and I am testing the stread_* functions I wrote 
> now.  I Figure the stwrite_* would also gain a huge 
> performance during operation of the mud.
> 
> Chris
> ----- Original Message -----
> From: "Jason Gauthier" <[EMAIL PROTECTED]>
> To: "'Chad Simmons'" <[EMAIL PROTECTED]>; "Chris Winston Litchfield"
> <[EMAIL PROTECTED]>
> Cc: <[email protected]>
> Sent: Friday, July 18, 2003 8:46 AM
> Subject: RE: Simple Performance Speedup.
> 
> 
> > Actually, it looks like he wants to boost performance at 
> mud startup. And
> > he's on the right track.
> > However, with fread_* functions you will always be limited 
> because of the
> > nature of the functions.
> >
> > If you truely want to increase mud boot time, here's what 
> you need to do.
> > Copy all the fread_functions to another function name (stread_*) for
> > example.
> > Instead of passing *fp, make it pass char *.
> >
> > Change all reference to 'fp' to the passed string (we'll 
> call it str)
> >
> > The in boot_db instead of passing the fp, read the entire 
> area file into a
> > string and pass it:
> >               stat(strArea, &areafile);
> >               area=calloc(areafile.st_size, 1);
> >               fread(area, areafile.st_size, 1, fpArea);
> >               fclose(fpArea);
> >               area[areafile.st_size-1]=0;
> >
> > This makes for less file operations.
> >
> > Example function:
> >
> > void load_area(char *str)
> > {
> >     AREA_DATA *pArea;
> >
> >     pArea = calloc(sizeof(*pArea),1);
> >
> >     strcpy(pArea->file_name, stread_word(str));
> >
> >     pArea->area_flags = AREA_LOADING;
> >     pArea->security = MAX_SECURITY;
> >     pArea->builders = strdup("None");
> >     pArea->vnum = top_area;
> >
> >     pArea->name = stread_string(str);
> >     pArea->credits = stread_string(str);
> >     pArea->min_vnum = stread_room_number(str);
> >     pArea->max_vnum = stread_room_number(str);
> >     pArea->age = 32;
> >     pArea->nplayer = 0;
> >     pArea->empty = FALSE;
> >
> >     if (!area_first)
> >       area_first = pArea;
> >     if (area_last) {
> >       area_last->next = pArea;
> >       REMOVE_BIT(area_last->area_flags, AREA_LOADING);
> >     }
> >     area_last = pArea;
> >     pArea->next = NULL;
> >     old_area=TRUE;
> >     top_area++;
> >     return;
> > }
> >
> > No, here's an example of stread_*:
> >
> > char * stread_string(char *str)
> > {
> >    static char plast[MSL*2];
> >    char c;
> >    int pc=0;
> >    do {
> >       c = str[str_pos];
> >       str_pos++;
> >     }
> >    while (c=='\n' || c==' ' || c=='\r');
> >     /* while (isspace((int)c)); */
> >
> >     if (c == '~')
> >      return &str_empty[0];
> >    str_pos--; // we need to shove this back a character
> >     for (;;) {
> >        plast[pc]  = str[str_pos];
> >        str_pos++;
> >        switch (plast[pc]) {
> >         case '\n':
> >           pc++;
> >           plast[pc] = '\r';
> >           break;
> >
> >         case '~':
> >           if (str[str_pos] == '\n' || str[str_pos] == '\r'){
> >              plast[pc] = '\0';
> >              return strdup(plast);
> >           }
> >        }
> >        pc++;
> >     }
> > }
> >
> >
> > Now, when you were using an fp, the OS keeps track of the 
> file location
> for
> > you.
> > Nothing keeps track of the string position.  This is what I 
> use str_pos
> for.
> >
> >
> > This alone lowered my mud booting time from 20 seconds to 1.
> >
> >
> > > -----Original Message-----
> > > From: Chad Simmons [mailto:[EMAIL PROTECTED]
> > > Sent: Friday, July 18, 2003 3:10 AM
> > > To: Chris Winston Litchfield
> > > Cc: [email protected]
> > > Subject: Re: Simple Performance Speedup.
> > >
> > >
> > >
> > > --- "Chris \"Winston\" Litchfield" <[EMAIL PROTECTED]> wrote:
> > > > Tip of the day.
> > > >
> > > > fread_string and other fread_* functions are used a lot.
> > > It would  make
> > > > sense that they be as fast as possible.......  it is why
> > > they are using HASH
> > > > tables for string combining...
> > > >
> > > > So.. a tip of the day.
> > > >
> > > > in db.c at the top make a variable called "charptrsize" an int.
> > > > in boot_db do:
> > > > charptrsize = sizeof(char *);
> > >
> > > [snip]
> > >
> > > > Instant SPEEDup.  Remember each unneeded function call adds
> > > a slight bit
> > > > slowdown.
> > >
> > >
> > > Firstly, if you are actually going to do this, you should use
> > > a const size_t
> > > not just an int, as it's not unsigned, and it's not going to
> > > change through
> > > program execution.
> > >
> > > Secondly, you're focusing on the wrong area. If you actually
> > > run ROM through a
> > > profiler, you'll see that the places ROM spends most of it's
> > > time is not in
> > > fread_string. In fact, these are only typically called at
> > > boot up, and when a
> > > new player connects.
> > >
> > > If you want to look for things to optimize, start with the
> > > update handlers. For
> > > example, creating a new linked list for the character data to
> > > quickly determine
> > > which creatures are currently in a fight will save your
> > > process a lot of time
> > > when it does the violence update every second or so. That's
> > > assuming you didn't
> > > really want to clean things up, in which case an event queue
> > > will really help
> > > with a lot of the empty loops which occur throught the ROM code.
> > >
> > > Just some suggestions,
> > >
> > > ~Kender
> > >
> > > =====
> > > -----BEGIN GEEK CODE BLOCK-----
> > > Version 3.1
> > > GCS/L/C/O d-(+) s++: a-- C+++$>++++ UBLS++++$
> > > P+++(--)$ L+++>++++ E--- W+>++$ N !o K? w(--) !O
> > > M- !V PS+ PE(++) Y+ PGP->+ t+ 5 X+() R(+) tv+@
> > > b++(+++) !DI+++ D G(-) e>+++$ h---() r+++ y+++
> > > ------END GEEK CODE BLOCK------
> > >
> > > __________________________________
> > > Do you Yahoo!?
> > > SBC Yahoo! DSL - Now only $29.95 per month!
> > > http://sbc.yahoo.com
> > >
> > > -- 
> > > ROM mailing list
> > > [email protected]
> > > http://www.rom.org/cgi-bin/mailman/listinfo/rom
> > >
> >
> >
> > -- 
> > ROM mailing list
> > [email protected]
> > http://www.rom.org/cgi-bin/mailman/listinfo/rom
> >
> >
> 
> 
> 
> -- 
> ROM mailing list
> [email protected]
> http://www.rom.org/cgi-bin/mailman/listinfo/rom
> 

Reply via email to