[issue23509] Speed up Counter operators

Roundup Robot added the comment: New changeset fe4efc0032b5 by Raymond Hettinger in branch '3.5': Issue #23509: Speed up Counter operators https://hg.python.org/cpython/rev/fe4efc0032b5 -- ___ Python tracker __

[issue23509] Speed up Counter operators

Serhiy Storchaka added the comment: Perhaps update __pos__ docstring? -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsu

[issue23509] Speed up Counter operators

Changes by Serhiy Storchaka : -- Removed message: http://bugs.python.org/msg244128 ___ Python tracker ___ ___ Python-bugs-list mailing

[issue23509] Speed up Counter operators

Serhiy Storchaka added the comment: Perhaps correct __pos__ docstring? -- ___ Python tracker ___ ___ Python-bugs-list mailing list Uns

[issue23509] Speed up Counter operators

Roundup Robot added the comment: New changeset 5780ee2c18e1 by Raymond Hettinger in branch 'default': Issue #23509: Speed up Counter operators https://hg.python.org/cpython/rev/5780ee2c18e1 -- nosy: +python-dev ___ Python tracker

[issue23509] Speed up Counter operators

Raymond Hettinger added the comment: The change to __neg__ looked like a nice improvement and the same should technique can be done to __pos__. Attaching a patch for those two. -- versions: +Python 3.6 -Python 3.5 Added file: http://bugs.python.org/file39497/counter_pos_neg.diff

[issue23509] Speed up Counter operators

Serhiy Storchaka added the comment: The OrderedCounter recipe doesn't support well multiset operations, because the result type is hardcoded to Counter. The order is already scrambled. update() and substract() don't work well with overloaded __missing__(). Proposed implementations of __add__ a

[issue23509] Speed up Counter operators

Jörn Hees added the comment: > I'm closing this because the OP's original concern about wanting an in-place > operation was already solved Was it? Are you referring to http://bugs.python.org/issue13121 ? My main concern was that += is considerably slower than .update(), kind of catching me of

[issue23509] Speed up Counter operators

Raymond Hettinger added the comment: Sorry, I don't want to any of these changes (though it is a close call on a couple of them). Before the particulars, here are some high-level thoughts (not definitive). I would like to confine the optimizations and complexities to the more important parts

[issue23509] Speed up Counter operators

Serhiy Storchaka added the comment: Could you please look at the patch Raymond? There are only few days are left to the feature freeze. -- keywords: +needs review ___ Python tracker ___

[issue23509] Speed up Counter operators

Serhiy Storchaka added the comment: Added explanation comments to address Victor's comment. -- Added file: http://bugs.python.org/file38708/counter_faster_2.patch ___ Python tracker

[issue23509] Speed up Counter operators

Serhiy Storchaka added the comment: Applied optimizations: 1) Used cached get() method instead of indexing. This optimization already was used in update() and subtract(). 2) _keep_positive() is optimized for the case when most counts are not positive (common case for substraction and intersect

[issue23509] Speed up Counter operators

Changes by Raymond Hettinger : -- assignee: -> rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http

[issue23509] Speed up Counter operators

Serhiy Storchaka added the comment: > - in the given patch __add__ uses __iadd__, but __sub__ doesn't use > __isub__, which seems a bit weird. If Counters are positive (common case), then the result of addition is not less than both summands. a + b is a and may be additional elements from b. In

[issue23509] Speed up Counter operators

Jörn Hees added the comment: cool minor question: - in the given patch __add__ uses __iadd__, but __sub__ doesn't use __isub__, which seems a bit weird. maybe off-topic, but maybe not, because of _keep_positive(self): - is there place for a non multi-set centric "Stats" object which is like C