I wish to revise my statement. After debugging the Hash interface, I was able to cut only 2 seconds off my boot time. It is 16 seconds. Apparently 4 of them was from the hash beign removed for a bug testing.
So Jason, how did you get rid of the Hashing for arrays? Chris ----- Original Message ----- From: "Chris "Winston" Litchfield" <[EMAIL PROTECTED]> Cc: <[email protected]> Sent: Sunday, July 20, 2003 9:24 PM Subject: Re: Simple Performance Speedup. > Okay, > > I have written the stread_* functions and made the areas work. saved 6 > seconds off my 18 second boot time. That is better. > > Any other performance increases you can think of? > > Thanks, > 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 > >
