[issue16465] dict creation performance regression

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

[issue16465] dict creation performance regression

2016-03-11 Thread Serhiy Storchaka
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

2014-08-06 Thread Antoine Pitrou
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

2014-08-06 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: Antoine, are you still oppose to this patch? -- assignee: -> serhiy.storchaka ___ Python tracker ___

[issue16465] dict creation performance regression

2014-03-06 Thread Josh Rosenberg
Changes by Josh Rosenberg : -- nosy: +ShadowRanger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail

[issue16465] dict creation performance regression

2014-02-14 Thread Peter Ingebretson
Changes by Peter Ingebretson : -- nosy: +pingebretson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://m

[issue16465] dict creation performance regression

2013-12-06 Thread Raymond Hettinger
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 ___

[issue16465] dict creation performance regression

2013-12-06 Thread Antoine Pitrou
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 impr

[issue16465] dict creation performance regression

2013-12-06 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: So what we should do with this? -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubs

[issue16465] dict creation performance regression

2013-02-28 Thread Christian Heimes
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 '{};{};{};{};{};{};{};{};{};{}'"; ech

[issue16465] dict creation performance regression

2013-01-09 Thread John O'Connor
Changes by John O'Connor : -- nosy: +jcon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.or

[issue16465] dict creation performance regression

2012-11-17 Thread Andrew Svetlov
Changes by Andrew Svetlov : -- nosy: +asvetlov ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue16465] dict creation performance regression

2012-11-16 Thread STINNER Victor
Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue16465] dict creation performance regression

2012-11-15 Thread Serhiy Storchaka
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 hard-

[issue16465] dict creation performance regression

2012-11-14 Thread Antoine Pitrou
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

2012-11-14 Thread Jesús Cea Avión
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

[issue16465] dict creation performance regression

2012-11-14 Thread Jesús Cea Avión
Changes by Jesús Cea Avión : -- nosy: +jcea ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue16465] dict creation performance regression

2012-11-14 Thread Serhiy Storchaka
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: http://bugs.python.org/file27983/dict_free

[issue16465] dict creation performance regression

2012-11-14 Thread Serhiy Storchaka
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

2012-11-14 Thread Antoine Pitrou
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 ar

[issue16465] dict creation performance regression

2012-11-14 Thread Serhiy Storchaka
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 o

[issue16465] dict creation performance regression

2012-11-13 Thread Antoine Pitrou
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 (non

[issue16465] dict creation performance regression

2012-11-13 Thread Raymond Hettinger
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 -- c

[issue16465] dict creation performance regression

2012-11-13 Thread Antoine Pitrou
Antoine Pitrou added the comment: Does this regression impact any real-world program? -- ___ Python tracker ___ ___ Python-bugs-list m

[issue16465] dict creation performance regression

2012-11-13 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: May be using the free list for keys will restore performance. -- nosy: +benjamin.peterson, pitrou ___ Python tracker ___ _

[issue16465] dict creation performance regression

2012-11-13 Thread Serhiy Storchaka
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 ___ ___

[issue16465] dict creation performance regression

2012-11-13 Thread Serhiy Storchaka
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

2012-11-13 Thread Philipp Hagemeister
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+ $