On 3 November 2016 at 02:03, Armin Rigo <armin.r...@gmail.com> wrote: > Hi Victor, > > On 2 November 2016 at 16:53, Victor Stinner <victor.stin...@gmail.com> wrote: >> 2016-11-02 15:20 GMT+01:00 Armin Rigo <armin.r...@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=1000 > > What I'm criticizing here is this instead: > > python2 -m perf timeit '[1,2]*1000' --duplicate=1000 --compare-to=pypy > > because 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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Speed mailing list Speed@python.org https://mail.python.org/mailman/listinfo/speed
