[Python-Dev] insertdict slower?

[M.-A. Lemburg]

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/