3 ms·
Unpacking kwargs is pretty much equivalent to building a dict. The major slowdown is 1) looking up dict and 2) calling a function: >>> def dict1(): ..
by j_baker 16y ago
Unpacking kwargs is pretty much equivalent to building a dict. The major slowdown is 1) looking up dict and 2) calling a function:
>>> def dict1():
... {"a" : 1, "b" : 2}
...
>>> from dis import dis
>>> dis(dict1)
2 0 BUILD_MAP 2
3 LOAD_CONST 1 (1)
6 LOAD_CONST 2 ('a')
9 STORE_MAP
10 LOAD_CONST 3 (2)
13 LOAD_CONST 4 ('b')
16 STORE_MAP
17 POP_TOP
18 LOAD_CONST 0 (None)
21 RETURN_VALUE
>>> def dict2():
... dict(a=1, b=2)
...
>>> dis(dict2)
2 0 LOAD_GLOBAL 0 (dict)
3 LOAD_CONST 1 ('a')
6 LOAD_CONST 2 (1)
9 LOAD_CONST 3 ('b')
12 LOAD_CONST 4 (2)
15 CALL_FUNCTION 512
18 POP_TOP
19 LOAD_CONST 0 (None)
22 RETURN_VALUE
Given that, I'd assume that the overhead doesn't grow as the dict grows.
- cma 16y agoAs python runtimes/JITs get better and better, the literal version could get relatively faster, since static assertions can potentially more easily be made about it; whereas the global 'dict' could be replaced with anything, requiring much more sophistication. Say you use a dict in a non-mutating manner, it is made up of string literals only, and you construct it within a loop; it could be able to be pulled out as an invariant, the same could be true of the function-call case, but potentially not as easily.
- barrkel 16y agoIn optimizing a dynamic language, the problem of a symbol being replaced like this is no big deal; it's all but the expected norm, and inline caching ought to take care of it. On invariant code motion: it tends not to be a big win because programmers usually move obvious big code out of loops explicitly. They do that because relying on a compiler optimization to do it is unpredictable; you may accidentally trigger a wall in your optimizer's ability to analyze your code as it grows more complex over time. But we really are arguing over small potatoes here.