[Python-Dev] insertdict slower?
M.-A. Lemburg
mal@lemburg.com
Fri, 02 Feb 2001 18:19:20 +0100
Jeremy Hylton wrote:
>
> >>>>> "TP" == Tim Peters <tim.one@home.com> writes:
>
> TP> [Jeremy]
> >> I was curious about what the DictCreation microbenchmark in
> >> pybench was slower (about 15%) with 2.1 than with 2.0. I ran
> >> both with profiling enabled (-pg, no -O) and see that insertdict
> >> is a fair bit slower in 2.1. Anyone with dict implementation
> >> expertise want to hazard a guess about this?
>
> TP> You don't need to be an expert for this one: just look at the
> TP> code! There's nothing to it, and not even a comment has changed
> TP> in insertdict since 2.0. I don't believe the profile.
>
> [...]
>
> TP> So you're looking at a buggy profiler, a buggy profiling
> TP> procedure, or a Cache Mystery (the catch-all excuse for anything
> TP> that's incomprehensible without HW-level monitoring tools).
> TP> [...]
>
> I wanted to be sure that some other change to the dictionary code
> didn't have the unintended consequence of slowing down insertdict.
> There is a real and measurable slowdown in MAL's DictCreation
> microbenchmark, which needs to be explained somehow. insertdict
> sounds more plausible than many other explanations. But I don't have
> any more time to think about this before the release.
The benchmark uses integers as keys, so Fred's string optimization
isn't used. Instead, PyObject_RichCompareBool() gets triggered and
this probably causes the slowdown.
You should notice a similar slowdown for all non-string keys.
Since dictionaries only check for equality, perhaps we should
tweak the rich compare implementation to provide a highly
optimized implementation for this single case ?!
--
Marc-Andre Lemburg
______________________________________________________________________
Company: http://www.egenix.com/
Consulting: http://www.lemburg.com/
Python Pages: http://www.lemburg.com/python/