From: Nicolas N. <Nic...@iw...> - 2004-11-03 09:42:51
|
Nikodemus Siivola <tsi...@cc...> writes: > One idea I that might or might not work is making EQ, EQL, EQUAL, > EQUALP, and user-specified hashtables all distinct structure-classes, > so that under right circumstances type-inference would allow inlining > comparison and hash-functions. This would probably pay off better if > support was added for type declarations of the form (hashtable > <hashtype>), though... blech. > > Just thinking out loud, I have done some further tests using numbers instead of symbols and comparing with an own simple eq-hash-table implementation along the lines you point out. I get a breakeven point for the number of objects at about 5 (compared to 40 for the built-in function). For num-obj=5, the built-in function is about three times slower, such that one can deduce a possible performance gain of a factor of 3 for GETHASH in this case. However, for practical applications things like cache misses might bring this factor near to 1. Therefore, I don't know what would be the overall benefit for SBCL and other applications (for my application Femlisp, there would probably be a larger benefit). But looking at the hash-table code in SBCL again, I think that doing this change is not easy. Nicolas. |