From: Paul F. D. <di...@dl...> - 2005-08-05 13:40:31
|
(Christophe suggested I post this here for Xach) I've added hash table caching to 0.9.3.30. This optimization causes the location in the hash table of the last access to be cached. On the next access, the key is compared (via EQ) with the key at that location (if the location is valid), and if they are the same the computation of the hash function is avoided. This speeds up the common 'retrieve/modify/store' and 'if not present, create' idioms. Paul |
From: Paul F. D. <di...@dl...> - 2005-08-05 18:34:33
|
I wrote: > This speeds up the common 'retrieve/modify/store' > and 'if not present, create' idioms. The second isn't true, since if the entry isn't in the hash table, this version of the optimization doesn't do anything. I plan to change it so that the case of a get on a non-present key followed by a put is also cached. There was a question on iRC about modifying keys used in hash table lookups. This can cause nasal demons, so we're allowed in the implementation to assume that it never happens. Also, I use EQ for the keys. I assume that any hash table test that we use has the property that (EQ x y) implies (<hash table test> x y). This is true for all the standard hash table tests (EQ, EQL, EQUAL, EQUALP). The converse need not be true, but that's ok. Paul |