[issue16465] dict creation performance regression

STINNER Victor added the comment: Serhiy Storchaka: > Closed in the favor of issue23601. Cool! -- ___ Python tracker ___

[issue16465] dict creation performance regression

Serhiy Storchaka added the comment: Closed in the favor of issue23601. -- resolution: -> out of date stage: patch review -> resolved status: open -> closed superseder: -> use small object allocator for dict key storage ___ Python tracker

[issue16465] dict creation performance regression

Serhiy Storchaka added the comment: Antoine, are you still oppose to this patch? -- assignee: - serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16465 ___

[issue16465] dict creation performance regression

Antoine Pitrou added the comment: The patch adds complication to the already complicated memory management of dicts. It increases maintenance burden in critical code. Have we found any case where it makes a tangible difference? (I'm not talking about timeit micro-benchmarks) -- nosy:

[issue16465] dict creation performance regression

Changes by Josh Rosenberg shadowran...@gmail.com: -- nosy: +ShadowRanger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16465 ___ ___

[issue16465] dict creation performance regression

Changes by Peter Ingebretson pinge...@yahoo.com: -- nosy: +pingebretson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16465 ___ ___

[issue16465] dict creation performance regression

Serhiy Storchaka added the comment: So what we should do with this? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16465 ___ ___

[issue16465] dict creation performance regression

Antoine Pitrou added the comment: You said it yourself: The gain is too small and undistinguished on a background of random noise. Closing would be reasonable, unless someone exhibits a reasonable benchmark where there is a significant difference. In any case, it's too late for perf

[issue16465] dict creation performance regression

Raymond Hettinger added the comment: This patch looks correct and like the right thing to do. I recommend applying it to 3.5. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16465 ___

[issue16465] dict creation performance regression

Christian Heimes added the comment: The patch gives a measurable speedup (./python is a patched 3.3.0+). IMO we should apply it. It's small and I can see no harm, too. $ for PY in python2.7 python3.2 python3.3 ./python; do cmd=$PY -R -m timeit -n 1000 '{};{};{};{};{};{};{};{};{};{}'; echo

[issue16465] dict creation performance regression

Changes by John O'Connor tehj...@gmail.com: -- nosy: +jcon ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16465 ___ ___ Python-bugs-list mailing

[issue16465] dict creation performance regression

Changes by Andrew Svetlov andrew.svet...@gmail.com: -- nosy: +asvetlov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16465 ___ ___

[issue16465] dict creation performance regression

Changes by STINNER Victor victor.stin...@gmail.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16465 ___ ___ Python-bugs-list

[issue16465] dict creation performance regression

Serhiy Storchaka added the comment: In the end, it's mostly a wash. Yes, it's predictable. The gain is too small and undistinguished on a background of random noise. May be more long-running benchmark will show more reliable results, but in any case, the gain is small. My long-running

[issue16465] dict creation performance regression

Serhiy Storchaka added the comment: As I understand, the new dict created on every call of function with keyword arguments. This slow down every such call about 0.1 µsec. This is about 10% of int('42', base=16). In the sum, some programs can slow down to a few percents. Direct comparison

[issue16465] dict creation performance regression

Antoine Pitrou added the comment: As I understand, the new dict created on every call of function with keyword arguments. This slow down every such call about 0.1 µsec. This is about 10% of int('42', base=16). Ok, but `int('42', base=16)` is about the fastest function call with keyword

[issue16465] dict creation performance regression

Serhiy Storchaka added the comment: Ok, but `int('42', base=16)` is about the fastest function call with keyword arguments one can think about :-) Not as fast as a call without keywords, `int('42', 16)`. :-( But this is a different issue. -- ___

[issue16465] dict creation performance regression

Serhiy Storchaka added the comment: Here is a really simple patch. It speed up to 1.9x an empty dict creation (still 1.6x slower than 3.2). Make your measurements of real-world programs. -- keywords: +patch stage: - patch review Added file:

[issue16465] dict creation performance regression

Changes by Jesús Cea Avión j...@jcea.es: -- nosy: +jcea ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16465 ___ ___ Python-bugs-list mailing list

[issue16465] dict creation performance regression

Jesús Cea Avión added the comment: Antoine, I would consider this a performance regression to solve for 3.3.1. Small dictionary creation is everywhere in CPython. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16465

[issue16465] dict creation performance regression

Antoine Pitrou added the comment: Antoine, I would consider this a performance regression to solve for 3.3.1. Small dictionary creation is everywhere in CPython. Again, feel free to provide real-world benchmark numbers proving the regression. I've already posted some figures. --

[issue16465] dict creation performance regression

New submission from Philipp Hagemeister: On my system, {} has become significantly slower in 3.3: $ python3.2 -m timeit -n 100 '{}' 100 loops, best of 3: 0.0314 usec per loop $ python3.3 -m timeit -n 100 '{}' 100 loops, best of 3: 0.0892 usec per loop $ hg id -i ee7b713fec71+ $

[issue16465] dict creation performance regression

Serhiy Storchaka added the comment: I confirm that. $ ./python -m timeit -n 100 '{};{};{};{};{};{};{};{};{};{}' 2.6: 0.62 usec 2.7: 0.57 usec 3.1: 0.55 usec 3.2: 0.48 usec 3.3: 1.5 usec Randomization is not affecting it. -- keywords: +3.3regression nosy: +serhiy.storchaka

[issue16465] dict creation performance regression

Serhiy Storchaka added the comment: Ah, this is an effect of PEP 412. The difference exists only for creating dicts up to 5 items (inclusive). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16465

[issue16465] dict creation performance regression

Serhiy Storchaka added the comment: May be using the free list for keys will restore performance. -- nosy: +benjamin.peterson, pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16465 ___

[issue16465] dict creation performance regression

Antoine Pitrou added the comment: Does this regression impact any real-world program? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16465 ___

[issue16465] dict creation performance regression

Raymond Hettinger added the comment: Does this regression impact any real-world program? That is a blow-off response. A huge swath of the language is affected by dictionary performance (keyword args, module lookups, attribute lookup, etc). Most programs will be affected to some degree --

[issue16465] dict creation performance regression

Antoine Pitrou added the comment: Does this regression impact any real-world program? That is a blow-off response. A huge swath of the language is affected by dictionary performance (keyword args, module lookups, attribute lookup, etc). I was merely suggesting to report actual