[Prev][Next][Index][Thread]

# Re: A few optimization questions...

- Date: Sun, 5 May 1996 12:53:50 PDT
- From:
- 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()

References:

- 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

Home | Subject Index | Thread Index