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
> 


Reply via email to