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 <>
@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",
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.
Date User Action Args
2020-10-02 06:55:18corona10setrecipients: + corona10, mark.dickinson, vstinner, serhiy.storchaka, ammar2, pablogsal
2020-10-02 06:55:18corona10setmessageid: <>
2020-10-02 06:55:18corona10linkissue41902 messages
2020-10-02 06:55:17corona10create