[issue27358] BUILD_MAP_UNPACK_WITH_CALL is slow

Changes by Donald Stufft : -- pull_requests: +1104 ___ Python tracker ___ ___

[issue27358] BUILD_MAP_UNPACK_WITH_CALL is slow

Serhiy Storchaka added the comment: Thanks Berker! This was temporary change for debugging. I forgot to remove it. -- ___ Python tracker ___

[issue27358] BUILD_MAP_UNPACK_WITH_CALL is slow

Roundup Robot added the comment: New changeset e2d4e077cfb2 by Berker Peksag in branch '3.6': Issue #27358: Fix typo in error message https://hg.python.org/cpython/rev/e2d4e077cfb2 New changeset 9abb316f1593 by Berker Peksag in branch 'default': Issue #27358: Merge from 3.6

[issue27358] BUILD_MAP_UNPACK_WITH_CALL is slow

Berker Peksag added the comment: test_unpack_ex fails on several buildbots: http://buildbot.python.org/all/builders/x86-64%20Ubuntu%2015.10%20Skylake%20CPU%203.6/builds/120/steps/test/logs/stdio test test_unpack_ex failed **

[issue27358] BUILD_MAP_UNPACK_WITH_CALL is slow

Changes by Serhiy Storchaka : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue27358] BUILD_MAP_UNPACK_WITH_CALL is slow

Roundup Robot added the comment: New changeset 148172f75d43 by Serhiy Storchaka in branch '3.6': Issue #27358: Optimized merging var-keyword arguments and improved error https://hg.python.org/cpython/rev/148172f75d43 New changeset 489ad68b35c0 by Serhiy Storchaka in branch 'default': Issue

[issue27358] BUILD_MAP_UNPACK_WITH_CALL is slow

Changes by Serhiy Storchaka : -- assignee: -> serhiy.storchaka versions: +Python 3.7 ___ Python tracker ___

[issue27358] BUILD_MAP_UNPACK_WITH_CALL is slow

Serhiy Storchaka added the comment: Updated patch addresses Victor's comments. -- Added file: http://bugs.python.org/file44799/faster_build_map_unpack_with_call2.patch ___ Python tracker

[issue27358] BUILD_MAP_UNPACK_WITH_CALL is slow

Serhiy Storchaka added the comment: Yes, it is expected perf regression compared to Python 3.5 and 2.7 when pass keyword arguments and single var-keyword argument (because 3.6 uses BUILD_MAP_UNPACK_WITH_CALL, while 2.7 and 3.5 don't need it for this case). In case of multiple var-keyword

[issue27358] BUILD_MAP_UNPACK_WITH_CALL is slow

STINNER Victor added the comment: > $ ./python -m timeit -s "def f(**kw): pass" -s "b = {'b': 2}" -- "f(a=1, **b)" > Unpatched: 10 loops, best of 3: 7.64 usec per loop > Patched:10 loops, best of 3: 3.14 usec per loop Impressive numbers but... is it a perf regression compared to

[issue27358] BUILD_MAP_UNPACK_WITH_CALL is slow

Serhiy Storchaka added the comment: Microbenchmarks: $ ./python -m timeit -s "def f(**kw): pass" -s "b = {'b': 2}" -- "f(a=1, **b)" Unpatched: 10 loops, best of 3: 7.64 usec per loop Patched:10 loops, best of 3: 3.14 usec per loop $ ./python -m timeit -s "def f(**kw): pass" -s "a

[issue27358] BUILD_MAP_UNPACK_WITH_CALL is slow

Serhiy Storchaka added the comment: The side effect of the last patch is fixing a regression in 3.6 and a bug in 3.5 (issue28257). -- ___ Python tracker

[issue27358] BUILD_MAP_UNPACK_WITH_CALL is slow

Serhiy Storchaka added the comment: Here is a patch that gets rid of calculating intersections. I didn't make benchmarking still. -- Added file: http://bugs.python.org/file44540/faster_build_map_unpack_with_call.patch ___ Python tracker

[issue27358] BUILD_MAP_UNPACK_WITH_CALL is slow

STINNER Victor added the comment: See also issue #27845: "Optimize update_keyword_args() function". -- nosy: +haypo ___ Python tracker ___

[issue27358] BUILD_MAP_UNPACK_WITH_CALL is slow

Serhiy Storchaka added the comment: I think this kills the optimization effect for non-dicts. See on PyDict_Merge(). It takes the boolean parameter that controls the behavior in case of matching keys. I think the best would be to rename it to say _PyDict_MergeEx(), extend the boolean

[issue27358] BUILD_MAP_UNPACK_WITH_CALL is slow

Emanuel Barry added the comment: `dict` subclasses can be hashable - it's a very bad idea, but not guarded against. If you were to do this, I'd suggest going the exception way, à la StopIteration. I wonder how feasible it would be for e.g. dict.__setitem__ to check if a key already exists;

[issue27358] BUILD_MAP_UNPACK_WITH_CALL is slow

Demur Rumed added the comment: (returning None wouldn't work because that may be the key, but something like returning the dict itself (ie an unhashable) or keeping this as a C API & returning NULL would work) -- ___ Python tracker

[issue27358] BUILD_MAP_UNPACK_WITH_CALL is slow

Demur Rumed added the comment: mapaca2 heavy handily deals with the must-work-with-all-mappings by converting any non dict mappings on the stack with dicts when with_call is true I'm not sure if it'd be better to seek a less opcode centric fix-- ie introduce a method to dictobject which

[issue27358] BUILD_MAP_UNPACK_WITH_CALL is slow

Serhiy Storchaka added the comment: The problem is that var-keyword argument can be not a dict, but general mapping. This optimization is applicable only if it is a dict. -- stage: -> patch review ___ Python tracker

[issue27358] BUILD_MAP_UNPACK_WITH_CALL is slow

Changes by Demur Rumed : -- nosy: +serhiy.storchaka ___ Python tracker ___ ___

[issue27358] BUILD_MAP_UNPACK_WITH_CALL is slow

Changes by Demur Rumed : -- components: +Interpreter Core type: -> performance versions: +Python 3.6 ___ Python tracker ___

[issue27358] BUILD_MAP_UNPACK_WITH_CALL is slow

New submission from Demur Rumed: BUILD_MAP_UNPACK_WITH_CALL is _really_ slow, wasting much of its time asserting that keys are non overlapping. This patch optimizes a fast path for distinct dicts, especially useful for #27213 where BUILD_MAP_UNPACK_WITH_CALL is generated for a single **kw