[issue29724] Itertools docs propose a harmful “speedup” without any explanation

STINNER Victor added the comment: > Victor will probably tell me I'm micro-benchmarking this the wrong way, so to satisfy him I did one more run: You are doing it the wrong way :-D Please replace Timeit(...) with runner=perf.Runner() and then runner.timeit('bench1', ...). Runner spaws multiples

[issue29724] Itertools docs propose a harmful “speedup” without any explanation

Raymond Hettinger added the comment: Additional note: For folks interested in performance, it is common for people not to realize that function call overhead can dominate their timings (see this recent SO question as a recent, but typical example http://stackoverflow.com/questions/41772054 ).

[issue29724] Itertools docs propose a harmful “speedup” without any explanation

Raymond Hettinger added the comment: The reason that this comment was added was to note the recipes themselves are unoptimized and to provide some guideance on how that could be done. The recipes themselves are provided in the cleaner looking form. FWIW, localizing variables is one of the few

[issue29724] Itertools docs propose a harmful “speedup” without any explanation

Changes by Raymond Hettinger : -- assignee: docs@python -> rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubsc

[issue29724] Itertools docs propose a harmful “speedup” without any explanation

Serhiy Storchaka added the comment: I have got 15% speed up. But two of my variants (the first and the second) speed up the calculation by 2.8 and 3.6 times correspondingly. It doesn't make sense to talk about microoptimization of the example if rewriting it without using iterator tools can g

[issue29724] Itertools docs propose a harmful “speedup” without any explanation

Leonid R. added the comment: I think this is a "last resort" optimization and shouldn't be encouraged, especially in the official documentation. There are plenty of real optimizations you can do before doing micro-optimizations like this, and there is no reason it should be mentioned in the do

[issue29724] Itertools docs propose a harmful “speedup” without any explanation

Marc-Andre Lemburg added the comment: The localization using keyword parameters is a very old trick to avoid global lookups. It does give a noticeable speedup, esp. when the localized variables are used in tight loops or the function itself is used in such loops. The 5% speedup Steven measured

[issue29724] Itertools docs propose a harmful “speedup” without any explanation

Serhiy Storchaka added the comment: How it comparing with return vec1[0]*vec2[0]+vec1[1]*vec2[1]+vec1[2]*vec2[2] and x1, y1, z1 = vec1 x2, y2, z2 = vec2 return x1*x2+y1*y2+z1*z2 and x1, y1, z1 = vec1 x2, y2, z2 = vec2 return sum(a*b for a, b in zip(vec1, vec2)) ?

[issue29724] Itertools docs propose a harmful “speedup” without any explanation

Steven D'Aprano added the comment: On my computer, running Python 3.5 and continuing to do other tasks while the tests are running, I get a reproducible 5% speedup by using the "default values" trick. Here's my code: import operator def dotproduct(vec1, vec2): return sum(map(operator.mul,

[issue29724] Itertools docs propose a harmful “speedup” without any explanation

Changes by Steven D'Aprano : -- nosy: +steven.daprano ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://m

[issue29724] Itertools docs propose a harmful “speedup” without any explanation

New submission from Chris Warrick: The itertools recipes list [0] ends with the following dubious advice: > Note, many of the above recipes can be optimized by replacing global lookups > with local variables defined as default values. For example, the dotproduct > recipe can be written as: > >