From: Paul F. Dietz <dietz@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.
From: Paul F. Dietz <dietz@dl...> - 2005-08-05 18:34:33
> 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.
Get latest updates about Open Source Projects, Conferences and News.