STINNER Victor added the comment: On my laptop, the revision introducing the performance regression is: --- changeset: 101858:5a62d682636e user: Brett Cannon <br...@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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28852> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
