MOO-cows Mailing List Archive

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

Re: *hash() and binary stuff



ThwartedEfforts writes:
> 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
you.

> 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.

	Pavel


References:

Home | Subject Index | Thread Index