[issue39737] Speed up list.__eq__ by about 6%

STINNER Victor added the comment: I suggest to use LTO + PGO optimizations when benchmarking Python: https://pyperformance.readthedocs.io/usage.html#how-to-get-stable-benchmarks Benchmarking is hard :-/ -- ___ Python tracker

[issue39737] Speed up list.__eq__ by about 6%

Serhiy Storchaka added the comment: Thank you for your contribution Dennis. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue39737] Speed up list.__eq__ by about 6%

Serhiy Storchaka added the comment: New changeset be7ead62db9a1db3e2cd997b0beffd4480e51f5c by sweeneyde in branch 'master': bpo-39737: Remove code repitition in list_richcompare (GH-18638) https://github.com/python/cpython/commit/be7ead62db9a1db3e2cd997b0beffd4480e51f5c --

[issue39737] Speed up list.__eq__ by about 6%

Raymond Hettinger added the comment: Speed-up or not, I concur that the new code it clearer. -- nosy: +rhettinger ___ Python tracker ___ __

[issue39737] Speed up list.__eq__ by about 6%

Dennis Sweeney added the comment: > Debug mode is not meaningful. > Visual Studio will optimize fully on release mode. Sorry if I wasn't clear--the original assembly difference I posted in (https://bugs.python.org/msg362665) was indeed using the "release" build configuration. My last comment

[issue39737] Speed up list.__eq__ by about 6%

Dong-hee Na added the comment: Debug mode is not meaningful. Visual Studio will optimize fully on release mode. -- ___ Python tracker ___ _

[issue39737] Speed up list.__eq__ by about 6%

Dennis Sweeney added the comment: > Hmm, Is this build on release mode? Yes--in debug mode, each Py_INCREF is these 8 instructions: 78BD071E mov ecx,dword ptr [_Py_RefTotal (79039700h)] 78BD0724 add ecx,1 78BD0727 mov dword ptr [_Py_RefT

[issue39737] Speed up list.__eq__ by about 6%

Dong-hee Na added the comment: > it appears that Visual Studio on Windows 10 was not doing the optimization > one might expect. Hmm, Is this build on release mode? -- ___ Python tracker __

[issue39737] Speed up list.__eq__ by about 6%

Dennis Sweeney added the comment: I made the requested changes to reflect that this is for code cleanliness rather than strictly for performance. However, it appears that Visual Studio on Windows 10 was not doing the optimization one might expect. In particular, here is the disassembly befor

[issue39737] Speed up list.__eq__ by about 6%

Serhiy Storchaka added the comment: I have doubts that such small change can lead to significant speed up. It is likely a compiler glitch. But this change makes the code clearer. If you remove a NEWS entry with a doubtful promise I will accept it. -- ___

[issue39737] Speed up list.__eq__ by about 6%

Dong-hee Na added the comment: IMHO, I can not see a noticeable performance improvement. I think that the modern compiler will optimize the reused variable. ;) The below result might be noise. [master] ./python.exe -m pyperf timeit "A = list(range(10**3)); B = list(range(10**3))" "A==B"

[issue39737] Speed up list.__eq__ by about 6%

Change by SilentGhost : -- nosy: +corona10, serhiy.storchaka, vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsu

[issue39737] Speed up list.__eq__ by about 6%

Change by Dennis Sweeney : -- keywords: +patch pull_requests: +18004 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18638 ___ Python tracker ___ _

[issue39737] Speed up list.__eq__ by about 6%

New submission from Dennis Sweeney : The following tiny change: diff --git a/Objects/listobject.c b/Objects/listobject.c index 3c39c6444b..3ac03b71d0 100644 --- a/Objects/listobject.c +++ b/Objects/listobject.c @@ -2643,8 +2643,7 @@ list_richcompare(PyObject *v, PyObject *w, int op) P