[Speed] Analysis of a Python performance issue

[Victor Stinner]

Le 19 nov. 2016 21:29, "serge guelton" <sguelton at quarkslab.com> a écrit :
> Thanks *a lot* victor for this great article. You not only very
> accurately describe the method you used to track the performance bug,
> but also give very convincing results.

You're welcome. I'm not 100% sure that adding the hot attrbute makes the
performance of call_method reliable at 100%. My hope is that the 70%
slowdown doesn't reoccur.

> I still wonder what the conclusion should be:
>
> - (this) Micro benchmarks are not relevant at all, they are sensible to
minor
>   factors that are not relevant to bigger applications

Other benchmarks had peaks: logging_silent and json_loads. I'm unable to
say if microbenchmarks must be used or not to cehck for performance
regression or test the performance of a patch. So I try instead to analyze
and fix performance issues.

At least I can say that temporary peaks are higher and more frequent on
microbenchmark.

Homework: define what is a microbenchmark :-)

> - There is a generally good code layout that favors most applications?

This is an hard question. I don't know the answer. The hot attributes put
tagged functions in a separated ELF section, but I understand that inside
the section, order is not deterministic.

Maybe the size of a function code matters too. What happens if a function
grows? Does it impact other functions?

>   Maybe some core function from the interpreter ?

I chose to only tag the most famous functions of the core right now. I'm
testing tagging functions of extensions like json but I'm not sure that the
result is significant.

> Why does PGO fails to
>   ``find'' them?

I don't use PGO on speed-python.

I'm not sure that is PGO is reliable neither (reproductible performance).

Victor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/speed/attachments/20161120/c685067e/attachment.html>