This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author corona10
Recipients ammar2, corona10, mark.dickinson, pablogsal, serhiy.storchaka, vstinner
Date 2020-10-02.06:55:17
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1601621718.06.0.62278450135.issue41902@roundup.psfhosted.org>
In-reply-to
Content
@vstinner @pablo @mark

On my local machine (without cpu isolation),
PR 22480 does not affect performance issues.

import pyperf

runner = pyperf.Runner()
runner.timeit(name="bench long divide",
              stmt="""
for i in range(1, 256):
    a = 10000 // i
""")

but I think that my benchmark does not cover the worst case.

I need to set up the CPU isolation environment but my resource is limited.
(I need a Linux machine with sufficient permission but not)


PR 22479 and PR 22480 has two sides of assumption.

PR 22479: PyNumber_FloorDivide is a heavy operation if the user thinks that this is an unnecessary operation it should be avoided.
(In this case divide by one)
PR 22480: PyNumber_FloorDivide should process handle unnecessary operations smartly.


In conclusion, I'd like to +1 on mark's decision.
- PR 22480: even though the divisor value is one, if the dividend is not qualified from PyLong_CheckExact it will not get an optimization path.
So it will not cover all the 'divide by one' case and it can cause performance issues.
- PR 22480: Always optimized if the user does not set a specific step value and this will be same effect on PR 22492.
History
Date User Action Args
2020-10-02 06:55:18corona10setrecipients: + corona10, mark.dickinson, vstinner, serhiy.storchaka, ammar2, pablogsal
2020-10-02 06:55:18corona10setmessageid: <1601621718.06.0.62278450135.issue41902@roundup.psfhosted.org>
2020-10-02 06:55:18corona10linkissue41902 messages
2020-10-02 06:55:17corona10create