[Tim] > ... to the contrary, it said lookdict got 4.5% *faster* in 2.1. Ack, I was reading the wrong column. It actually said that lookdict went from 0.48 to 0.49 seconds, while insertdict went from 0.20 to 0.26. http://mail.python.org/pipermail/python-dev/2001-February/012428.html Whatever, the profile isn't pointing at things that make sense, and is pointing at things that don't. Then again, why anyone would believe any output from a computer program is beyond me <wink>. needs-sleep-ly y'rs - tim PS: Sorry to say it, but rich comparisons have nothing to do with this either! Run your dict creation test under a debugger and watch it -- the rich compares never get called. The basic reason is that hash(i) == i for all Python ints i (except for -1, but you're not using that). So the hash codes in your dict creation test are never equal. But there's never a reason to call a "real compare" unless you hit a case where the hash codes *are* equal. The latter never happens, so neither does the former. The insert either finds an empty slot at once (& so returns immediately), or collides. But in the latter case, as soon as it sees that ep->me_hash != hash, it just moves on the next slot in the probe sequence; and so until it does find an empty slot.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4