On Sat, Mar 06, 2004 at 12:17:50PM -0800, Dan Quinlan wrote: > In addition, using hash tokens is more of a requirement due to size > reasons if we do multiple token stuff like CRM114 or DSPAM.
I was thinking about that this afternoon actually. That's a definite upshot of hashing. > This is in a simple benchmark, it could still be much better or much > worse and you're still neglecting the major disk space benefits for a > 32bit key. Not really -- see my last mail about it. There is only a slight space benefit when using DB_File, about 10%, when using 4-byte or 8-byte tokens instead of the raw average 12-byte tokens. 10% isn't bad, but that's pretty much the only benefit using the current code since speed is overall the same. > That seems like a premature conclusion, although if you want to conclude > we cannot simply slap hashing into our code, then I agree *that* would > not be worth it. That's pretty much what I'm saying -- I have no problem using the hash tokens in general, and if we could find a way to make them give a large enough benefit to switch to them (such as doing the "multiple token stuff", more efficient DB access than DB_File, etc,) I'm all for it. It felt as if this were being discussed in terms of getting something into 3.0 though, which is just not going to happen for pretty much all the reasons already stated: not enough benefit to just switching to hash tokens, and too much change/not enough time to find/put in new code which would deal with hashes more efficiently. Hence my posts with a generally negative attitude... As long as we're clear about that, no problems. :) -- Randomly Generated Tagline: Why does the Lifestyles of the Rich and Famous theme song sound like the theme song from Charlie's Angels?
pgp8dPUS1SRy9.pgp
Description: PGP signature
