> -----Original Message----- > From: Chris "Winston" Litchfield [mailto:[EMAIL PROTECTED] > Sent: Monday, July 21, 2003 5:36 PM > Cc: rom@rom.org > Subject: Re: Simple Performance Speedup. > > > I have 155 areas and then once loaded I do some checking on > things such as: Does a key have an room/object? Does a locked > room have a key? Do room exits loop themselves?
I wrote a very elaborate command called 'audit' that does this for me. I make my builders use it. When they are done, I use it too. I make sure the areas are clean, and then load them. I contributed this awhile ago, if you cannot find it, I'll re-submit it. It requires modification to use on any mud. > all sorts of building checks are done to contribute to the > now 13 second boot time :) [EMAIL PROTECTED]:~/pendulus/area$ ../pendulus/rom 1234 Fix_mobprogs: code vnum 8406 not found (mob: 8406). Mon Jul 21 23:26:32 2003: Pendulus is ready on port 1234. (pid: 14307) Booted: Usr time: 0.71000 Sys time: 0.17000 Real time: 0.90897 Page faults: 336 Page reclaims: 15950 Swaps: 0 -=-=-=-= Affects 4730 Areas 117 ExDes 1995 Exits 21320 Helps 551 Socials 245 Mobs 3405 (in use)14772 Objs 5319 Resets 20095 Rooms 353107 Shops 286 My theory is there is always room for improvement! But to get this any faster is beyond my abilities. (in pure code) > Chris > ----- Original Message ----- > From: "Jason Gauthier" <[EMAIL PROTECTED]> > To: "'Chris "Winston" Litchfield'" <[EMAIL PROTECTED]> > Cc: <rom@rom.org> > Sent: Monday, July 21, 2003 1:48 PM > Subject: RE: Simple Performance Speedup. > > > > Holy crap, that's very impressive. > > If you have a large number of rooms, the hashing of vnums > slows things > down. > > I removed all hashing, and created arrays. > > > > But, this only makes a difference if your mud is huge. (I have 350k) > rooms. > > > > That's it off the top of my head. > > > > > > > > > > -----Original Message----- > > > From: Chris "Winston" Litchfield [mailto:[EMAIL PROTECTED] > > > Sent: Sunday, July 20, 2003 9:25 PM > > > Cc: rom@rom.org > > > > > > 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: <rom@rom.org> > > > 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: rom@rom.org > > > > > 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 > > > > ROM@rom.org > > > > http://www.rom.org/cgi-bin/mailman/listinfo/rom > > > > > > > > > > > > > -- > > > ROM mailing list > > > ROM@rom.org > > > http://www.rom.org/cgi-bin/mailman/listinfo/rom > > > > > > > > > > > > > > -- > > ROM mailing list > > ROM@rom.org > > http://www.rom.org/cgi-bin/mailman/listinfo/rom > > > > -- > ROM mailing list > ROM@rom.org > http://www.rom.org/cgi-bin/mailman/listinfo/rom > > -- ROM mailing list ROM@rom.org http://www.rom.org/cgi-bin/mailman/listinfo/rom
