On 3 November 2016 at 02:03, Armin Rigo armin.rigo@gmail.com wrote:
Hi Victor,
On 2 November 2016 at 16:53, Victor Stinner victor.stinner@gmail.com wrote:
2016-11-02 15:20 GMT+01:00 Armin Rigo armin.rigo@gmail.com:
Is that really the kind of examples you want to put forward?
I am not a big fan of timeit, but we must use it sometimes to micro-optimizations in CPython to check if an optimize really makes CPython faster or not. I am only trying to enhance timeit. Understanding results require to understand how the statements are executed.
Don't get me wrong, I understand the point of the following usage of timeit:
python2 -m perf timeit '[1,2]*1000' --duplicate=1000What I'm criticizing here is this instead:
python2 -m perf timeit '[1,2]*1000' --duplicate=1000 --compare-to=pypybecause you're very unlikely to get any relevant information from such a comparison. I stand by my original remark: I would say it should be an error or at least a big fat warning to use --duplicate and PyPy in the same invocation. This is as opposed to silently ignoring --duplicate for PyPy, which is just adding more confusion imho.
Since the use case for --duplicate is to reduce the relative overhead of the outer loop when testing a micro-optimisation within a *given* interpreter, perhaps the error should be for combining --duplicate and --compare-to at all? And then it would just be up to developers of a *particular* implementation to know if "--duplicate" is relevant to them.
Regards, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia