MOO-cows Mailing List Archive
Re: *hash() and binary stuff
> We needed a hash() function on E_MOO to speed the lookups of commands for
> the in-database parser. I was susposed to be provided with a function to do
> this, but never was, then beta3 was released with series of hash functions.
> Unfortunately, they all return strings, which kind of defeats the purpose of
> using a hash function to speed string lookups.
ACK! You don't want to do this with the *_hash() functions. They're all using
MD5 to compute the hash and that is *not* a fast hash function in the sense of
ordinary hash tables. Instead, it's a cryptographically-secure hash function
that you can really count on returning different values for different inputs,
no matter how large the input. The intended use is to allow inter-MOO equality
tests for large values without having to send the whole value across for local comparison.
> I intended to truncate the returned value, and convert to a decimal value.
This is going to take you so long that any difference in the speed of `in'
between strings and numbers will be completely in the noise. I recommend that
you not worry about hashing and just do `in' in a list of strings and let the
100-fold difference in MOO vs. server execution take care of the problem for
> Right now, I'm looping over a series of lists, using a bf called
> verbname_match(), which essentially calls the function elsewhere in the
> server that does verb name matching and has the same name, on each string;
> thus, doing a string compare. I was hoping hashing could avoid the 400-800
> or so string compares I do.
Using caching instead, and use `in' on whatever subsets of the problem you can.
Subject Index |