Home Original page

[Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered

Serhiy Storchaka storchaka at gmail.com
Thu Sep 15 14:30:37 EDT 2016 
On 15.09.16 19:13, Antoine Pitrou wrote:
> Since this micro-benchmark creates the keys in order just before
> filling the dict with them, randomizing the insertion order destroys
> the temporal locality of object header accesses when iterating over the
> dict keys. *This* looks like the right explanation, not branch
> mispredicts due to NULL checks.
>
> This also shows that a micro-benchmark that merely looks ok can actually
> be a terrible proxy of actual performance.

Thanks you for great explanation Antoine! I came to the same conclusions 
about randomized integers example, but didn't notice that this also is a 
main cause of the speed up of strings example.

> As a further validation of this theory, let's dramatically decrease the
> working set size on the initial benchmark:
>
> $ ./python -m timeit -s "d=dict.fromkeys(map(str,range(10**3)))"
> "list(d)"
>
> -> Python 3.5: 100000 loops, best of 3: 10.9 usec per loop
> -> Python 3.6: 100000 loops, best of 3: 9.72 usec per loop
>
> When the working set fits in the cache, this micro-benchmark is
> only 12% slower on 3.5 compared to 3.6.
> *This* much smaller difference (a mere 1.2ns difference per dict
> element) could be attributed to eliminating the NULL checks, or to any
> other streamlining of the core iteration logic.

Yet one example, with random hashes and insertion order independent from 
the creation order.

$ ./python -m timeit -s "import random; a = list(map(str, 
range(10**6))); random.shuffle(a); d = dict.fromkeys(a)" -- "list(d)"

Python 3.5: 180, 180, 180 msec per loop
Python 3.6: 171, 172, 171 msec per loop

Python 3.6 is 5% faster and this looks closer to the actual performance.
More information about the Python-Dev mailing list