Micro optimization for longrange iteration if step is 1

[corona10]

BPO	42147
Nosy	@rhettinger, @mdickinson, @vstinner, @methane, @serhiy-storchaka, @corona10, @pablogsal
PRs	bpo-42147: Micro optimization for longrange_iterator if step is 1. #22971
Files	bench_longrange.py

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/corona10'
closed_at = <Date 2020-10-26.13:35:50.504>
created_at = <Date 2020-10-25.14:25:05.360>
labels = ['interpreter-core', '3.10', 'performance']
title = 'Micro optimization for longrange iteration if step is 1'
updated_at = <Date 2020-10-26.13:35:50.504>
user = 'https://github.com/corona10'

bugs.python.org fields:

activity = <Date 2020-10-26.13:35:50.504>
actor = 'corona10'
assignee = 'corona10'
closed = True
closed_date = <Date 2020-10-26.13:35:50.504>
closer = 'corona10'
components = ['Interpreter Core']
creation = <Date 2020-10-25.14:25:05.360>
creator = 'corona10'
dependencies = []
files = ['49539']
hgrepos = []
issue_num = 42147
keywords = ['patch']
message_count = 19.0
messages = ['379578', '379586', '379587', '379588', '379590', '379605', '379627', '379628', '379630', '379631', '379632', '379633', '379634', '379635', '379636', '379651', '379654', '379655', '379663']
nosy_count = 7.0
nosy_names = ['rhettinger', 'mark.dickinson', 'vstinner', 'methane', 'serhiy.storchaka', 'corona10', 'pablogsal']
pr_nums = ['22971']
priority = 'normal'
resolution = 'rejected'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'performance'
url = 'https://bugs.python.org/issue42147'
versions = ['Python 3.10']

[corona10]

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 -> [longrange_opt] 5.72 us +- 0.07 us: 1.13x faster (-11%)

[serhiy-storchaka]

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.

[corona10]

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

[corona10]

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.

[corona10]

if somebody try to sum very large value with range.
sum(range(1 << 1000, (1 << 1000) + 100))
it can be affected by this patch.

[pablogsal]

I concur with Serhiy

[methane]

I agree that 1<<1000 is artificial example. But isn't this patch affects more regular patterns like [[] for _ in range(10000)]?

If we reject this, shouldn't we revert #66669 too?
I believe iterating range object is much more common use case than range.index.

[pablogsal]

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 this case, I agree that the code is simple enough, but I still feel that the cost may not be worth the extra maintenance needs of those branches.

[methane]

I had not noticed that there are rangeobject and longrangeobject. It doesn't affect to range(10000) definitely.

[corona10]

@methane

To be more precise, [[] for _ in range(10000)] will not effort this patch because range(10000) does not create longrangeiter object.
This patch will affect to if the number is veeery large.

On the other hand, #66669 is affect to all index API() whether the number is large or small.

p.s by the way, Naoki is the last name or first name? ;)

[corona10]

s / will not effort / will not be affected