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