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/
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