[Speed] Latest enhancements of perf 0.8.1 and performance 0.3.1

[Nick Coghlan]

On 3 November 2016 at 02:03, Armin Rigo <armin.rigo at gmail.com> wrote:
> Hi Victor,
>
> On 2 November 2016 at 16:53, Victor Stinner <victor.stinner at gmail.com> wrote:
>> 2016-11-02 15:20 GMT+01:00 Armin Rigo <armin.rigo at 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   |   ncoghlan at gmail.com   |   Brisbane, Australia