Re: A few optimization questions...

• Date: Sun, 5 May 1996 12:53:50 PDT
• From:
  cadams@weather.brockport.edu (Chuck Adams)
• Cc: moo-cows@parc.xerox.com
• Content-Transfer-Encoding: 7bit
• Content-Type: text/plain; charset=US-ASCII
• In-Reply-To: <Pine.LNX.3.91.960503200743.1012A-100000@darkowl.pr.mcs.net> from "Don Schwarz" at May 3, 96 06:42:22 pm

Don Schwarz drew these hieroglyphs:
> Also, is:
>   <some large string> in { <a list of about 25 equally large strings> }
> faster (and less CPU intensive) than:
>   string_hash( <some large string> ) in { <a list of 25 MD5 hashes> }
> Yes, I know value_hash() wasn't made for this kind of thing, but it's
> still faster than making a hash in-DB.

string_hash() is not a particularly fast hash function.  It also
returns a string, which is particularly slow in comparisons.  at
E_MOO, we wrapped the strhash() function in the server into a builtin.
Unfortunately, its range is pretty small, resulting in collisions, but
it is fast.  I'll probably go with crc32() when I find it.  ANd yes,
we use it for exactly the same thing you're looking to use
string_hash() for.  It sped up our in-db parser by ... tef, you got
the numbers?  Suffice to say, a lot.

A $generic_db is probably what you want, if the list is large and not
changed often.


> And lastly, would it be worthwhile to write a special built-in function for
> something that runs approx. 10 times per call to $player:notify, to be used
> instead of:
>   match(foo, "%[%w%w:[a-zA-Z0-9:_]*%]")[1..2]

gack -- you should consider re-engineering whatever process is making
you put that kind of CPU-sucking code in every :notify()

• A few optimization questions...
• From: Don Schwarz <darkowl@darkowl.pr.mcs.net>

• Prev: Re: A few optimization questions...
• Next: flying things
• Index: MOO-cows
• Thread: MOO-cows