Message282213
On my laptop, the revision introducing the performance regression is:
---
changeset: 101858:5a62d682636e
user: Brett Cannon <brett@python.org>
date: Fri Jun 10 14:37:21 2016 -0700
files: Doc/library/os.rst Lib/test/test_os.py Misc/NEWS Modules/posixmodule.c
description:
Issue #27186: Add os.PathLike support to DirEntry
Initial patch thanks to Jelle Zijlstra.
---
This change is unrelated to sorted(list). It looks more like a "random performance" caused by code placement:
* https://haypo.github.io/analysis-python-performance-issue.html
* https://haypo.github.io/journey-to-stable-benchmark-deadcode.html
According to perf record/perf report, the benchmark spends most of its time in PyObject_RichCompareBool() and long_richcompare():
Overhead Command Shared Object Symbol
41,98% python python [.] PyObject_RichCompareBool
35,36% python python [.] long_richcompare
8,52% python python [.] listsort
6,29% python python [.] listextend
5,31% python python [.] list_dealloc
So I guess that the exact code placement of these two functions has a "signifiant" impact on performance. "Significant":
* rev b0be24a2f16c (fast): Median +- std dev: 15.0 us +- 0.1 us
* rev 5a62d682636e (slow): Median +- std dev: 16.3 us +- 0.0 us
The revision 5a62d682636e makes sorted(list) 9% slower.
--
Enabling PGO on compilation should help to get a more reliable code placement, and so more stable performances.
I suggest to close this issue as NOTABUG: ./configure --with-pgo should already fix this issue. |
|
Date |
User |
Action |
Args |
2016-12-02 02:01:35 | vstinner | set | recipients:
+ vstinner, ericvw, serhiy.storchaka |
2016-12-02 02:01:35 | vstinner | set | messageid: <1480644095.43.0.0716408307774.issue28852@psf.upfronthosting.co.za> |
2016-12-02 02:01:35 | vstinner | link | issue28852 messages |
2016-12-02 02:01:32 | vstinner | create | |
|