[issue42147] Micro optimization for longrange iteration if step is 1

Dong-hee Na added the comment: I close this issue with rejected status. Thank you serhiy, pablogsal and Inada-san for discussion ;) -- resolution: -> rejected stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue42147] Micro optimization for longrange iteration if step is 1

Dong-hee Na added the comment: I will close this issue by tomorrow with rejected ;) -- ___ Python tracker ___ ___ Python-bugs-list

[issue42147] Micro optimization for longrange iteration if step is 1

Dong-hee Na added the comment: > Sometimes the work of the core developer is to say "No" to his own code. Thank you for the careful sentence. For clear the air, I never think that my patch should be accepted. This is why I always get reviews from other core devs and I always accept the review

[issue42147] Micro optimization for longrange iteration if step is 1

Serhiy Storchaka added the comment: I think that In sum(range(1 << 1000, (1 << 1000) + 100)) it is dwarfed by repeated addition of long integers in sum(). I expect the the effect of this optimization is even less that 13% in this case. In any case, for sum(range(a, b)) it is better to use fo

[issue42147] Micro optimization for longrange iteration if step is 1

Inada Naoki added the comment: Oh, I didn't know that. Thank you. I thought Chinese and Korean use surname-given name order because of "Xí Jìnpíng", "Moon Jae-in", and "Kim Jong-un". Japanese previous P.M. used "Shinzo Abe" English notation, but changed it to "Abe Shinzo" recently. -

[issue42147] Micro optimization for longrange iteration if step is 1

Dong-hee Na added the comment: Sorry for the offtopic @methane Looks like Inada san is the right expression. ;) > But China and Korea don't reverse name. This is a very intereting fact, the national system of Korea are using surname-given name order or printing with a distinc section. A g

[issue42147] Micro optimization for longrange iteration if step is 1

Inada Naoki added the comment: > On the other hand, GH-22479 is affect to all index API() whether the number > is large or small. Then, no need to revert GH-22479 for consistency. Thanks. > p.s by the way, Naoki is the last name or first name? ;) It is difficult to say what is first name. I

[issue42147] Micro optimization for longrange iteration if step is 1

Dong-hee Na added the comment: @pablogsal, @serhiy.storchaka > I would advise against having more branching, especially for code that is > rare: About bpo-41902, I believe those patches affect all range objects which is created with step is one . I believe the usage of creation of range ob

[issue42147] Micro optimization for longrange iteration if step is 1

Dong-hee Na added the comment: s / will not effort / will not be affected -- ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue42147] Micro optimization for longrange iteration if step is 1

Dong-hee Na added the comment: @methane To be more precise, [[] for _ in range(1)] will not effort this patch because range(1) does not create longrangeiter object. This patch will affect to if the number is veeery large. On the other hand, GH-22479 is affect to all index API() wheth

[issue42147] Micro optimization for longrange iteration if step is 1

Inada Naoki added the comment: I had not noticed that there are rangeobject and longrangeobject. It doesn't affect to range(1) definitely. -- ___ Python tracker ___ _

[issue42147] Micro optimization for longrange iteration if step is 1

Pablo Galindo Salgado added the comment: My particular opinion is that I would advise against having more branching, especially for code that is rare: it augments the possibilities of branch mispredictions, the changes of untested code paths, and the possibilities of unknown interactions. In

[issue42147] Micro optimization for longrange iteration if step is 1

Inada Naoki added the comment: I agree that 1<<1000 is artificial example. But isn't this patch affects more regular patterns like [[] for _ in range(1)]? If we reject this, shouldn't we revert GH-22479 too? I believe iterating range object is much more common use case than range.index.

[issue42147] Micro optimization for longrange iteration if step is 1

Pablo Galindo Salgado added the comment: I concur with Serhiy -- nosy: +pablogsal ___ Python tracker ___ ___ Python-bugs-list maili

[issue42147] Micro optimization for longrange iteration if step is 1

Dong-hee Na added the comment: if somebody try to sum very large value with range. sum(range(1 << 1000, (1 << 1000) + 100)) it can be affected by this patch. -- ___ Python tracker ___

[issue42147] Micro optimization for longrange iteration if step is 1

Dong-hee Na added the comment: s/ I approach as same case that step=1 is quite a lot usecase until user designate step value. /My assumtion is that step=1 is quite often usecase until user designate step value. -- ___ Python tracker

[issue42147] Micro optimization for longrange iteration if step is 1

Dong-hee Na added the comment: At bpo-41092, we decide not to optimize mulitply operation itself. I approach as same case that step=1 is quite a lot usecase until user designate step value. If range with longobject is not that much use case, I can agree with your opinion -- __

[issue42147] Micro optimization for longrange iteration if step is 1

Serhiy Storchaka added the comment: Sorry, but I do not think it is worth. If there are any issues with multiplying by 1, it may be worth to optimize multiplication of integers in general. But iterating range(1 << 1000, (1 << 1000) + 100) looks a pretty artificial example. -- nosy: +

[issue42147] Micro optimization for longrange iteration if step is 1

Change by Dong-hee Na : -- keywords: +patch pull_requests: +21886 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22971 ___ Python tracker ___

[issue42147] Micro optimization for longrange iteration if step is 1

New submission from Dong-hee Na : This is a similar case with https://bugs.python.org/issue41902 A quite possible usecase when the user use range with big number ./python -m pyperf compare_to longrange_master.json longrange_opt.json Mean +- std dev: [longrange_master] 6.45 us +- 0.09 us -> [lon