Performance of map vs starmap.

[Serhiy Storchaka]

30.10.17 12:10, Kirill Balunov пише:
> Sometime ago I asked this question at SO [1], and among the responses
> received was paragraph:
> 
>   - `zip` re-uses the returned `tuple` if it has a reference count of 1 when
> the `__next__` call is made.
>   - `map` build a new `tuple` that is passed to the mapped function every
> time a `__next__` call is made.
> 
> Why can not `map` use the same approach as `zip`?
> 
> Also it turns out that a faster solution looks not reasonable, since it
> requires additional calculations..
> 
> [1] https://stackoverflow.com/questions/46172018/perfomance-
> of-map-vs-starmap

Sometime ago I had wrote a sample patch for using cached arg tuples in 
map() and several other functions [1]. It increased the speed in 
microbenchmarks up to 24-38%. But the code was too complex and fragile, 
I didn't want to commit it. Later, after numerous of attempts, this 
resulted in implementing by Victor Stinner the new private "fastcall" 
calling method which allowed to avoid creation a new tuple (and a dict 
for keyword arguments) in many cases. It was added just before releasing 
of 3.6 and was used in few places. In 3.7 it was optimized further. Now 
map() is faster than starmap()+zip().

Python 3.6:

$ ./python -m timeit -s 'from operator import eq; from itertools import 
starmap; seq1 = [1]*10000; seq2 = [1]*10000' 'list(map(eq, seq1, seq2))'
1000 loops, best of 3: 559 usec per loop

$ ./python -m timeit -s 'from operator import eq; from itertools import 
starmap; seq1 = [1]*10000; seq2 = [1]*10000' 'list(starmap(eq, zip(seq1, 
seq2)))'
1000 loops, best of 3: 399 usec per loop

Python 3.7:

$ ./python -m timeit -s 'from operator import eq; from itertools import 
starmap; seq1 = [1]*10000; seq2 = [1]*10000' 'list(map(eq, seq1, seq2))'
1000 loops, best of 5: 338 usec per loop

$ ./python -m timeit -s 'from operator import eq; from itertools import 
starmap; seq1 = [1]*10000; seq2 = [1]*10000' 'list(starmap(eq, zip(seq1, 
seq2)))'
1000 loops, best of 5: 359 usec per loop

[1] https://bugs.python.org/issue23507