On Fri, 23 Aug 1996, Sammy wrote:
> All it does is buffer the last mob, object, and room so if you load the
> same mob twice it doesn't search the whole index again.
Hey, I like that idea, I mean, it doesnt harm anyone, and though someone
took the time to explain the 'few' lookups needed in a binary search, it's
probably not going to be slower the way you sugested *grin*
I just thought I'd like to add this 'one thing' to your post/code, though
I didn't test your code yet, it seemed to be bugfree from what I checked.
Anyway, it's my oppinion that it's better to place the 'global'
declarations you sugested internally in each real_xx procedure like:
static sh_int lastreal;
and change the xxx_sbuf entries in each of the real_xxx() routines to
facilitate the lastreal variable instead. This way the variable would be
'acting' as if it was external (i.e. it's the same at next call to the
procedure), but it would not mess with other global variable declarations,
and thus in my oppinion keep the code slightly more tidy..
Just my two cents,
Con.
Btw. one of the routines would look like this:
int real_room(int virtual)
{
static sh_int lastreal; /* I ADDED THIS */
int bot, top, mid;
bot = 0;
top = top_of_world;
if((world + lastreal)->number == virtual) /* changed here */
return lastreal; /* changed here */
for (;;) {
mid = (bot + top) >> 1;
if ((world + mid)->number == virtual) {
lastreal = mid; /* changed here */
return mid;
}
if (bot >= top)
break;
if ((world + mid)->number > virtual)
top = mid - 1;
else
bot = mid + 1;
}
return(NOWHERE); /* in the dist it's return(-1) ...*/
} /* I guess it doesnt matter... *g* */
Regards,
Con.
d.
--
Rasmus Rønlev DOEK'94 WWW: http://www.econ.cbs.dk/people/raro94ab
Student instructor MUD: exiled.mud.circlemud.org 5000
199.199.16.100 5000
Student, B.Sc in Computer Science and Business Administration.
+-----------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://cspo.queensu.ca/~fletcher/Circle/list_faq.html |
+-----------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/07/00 PST