Message391557
| Author |
vstinner |
| Recipients |
corona10, erlendaasland, miss-islington, pablogsal, petr.viktorin, phsilva, rhettinger, serhiy.storchaka, shihai1991, vstinner |
| Date |
2021年04月21日.23:12:33 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1619046754.22.0.498498641989.issue40137@roundup.psfhosted.org> |
| In-reply-to |
| Content |
New microbenchmark on the functools.lru_cache(lambda: 42) function using my 3 optimizations on _PyType_GetModuleByDef():
* commit d4aaa34798f0dd8402f412e2aa9d6fa2d6cff5fa
* commit 760da626ff4124e1344fd8b7dbeb83b2c4b7c12c
* commit cdad2724e6f7426372901cc5dedd8a462ba046a6
* I didn't pick Raymond's optimization for this benchmark, so I can still use _functools for my benchmark.
$ python3 -m pyperf compare_to py39.json master.json
Mean +- std dev: [py39] 38.8 ns +- 0.5 ns -> [master] 39.2 ns +- 0.9 ns: 1.01x slower
The _PyType_GetModuleByDef() overhead in _functools is now about +0.4 ns, it's better than my previous measurement before optimization: +5.7 ns (37.5 ns +- 1.0 ns -> 43.2 ns +- 0.7 ns).
These timings are really tiny, it's really hard to get reliable timing even with CPU isolation. For example, two measurements on Python 3.9:
* Old measurement: 37.5 ns +- 1.0 ns
* New measurement: 38.8 ns +- 0.5 ns
I guess that for timings under 100 ns, the PGO build is no longer reliable enough. Moreover, the std dev is around to 1 ns on 40 ns. |
|