Triage the open "performance" issues on cpython repo

[iritkatriel]

There are 243 open issues with the "performance" label on cpython repo:

https://github.com/python/cpython/issues?q=is%3Aissue+is%3Aopen+label%3Aperformance+created%3A%3C2022-08-01+-label%3A3.12

[erlend-aasland]

Create a GH Project for it so it is easier to break it into smaller, manageable pieces.

[iritkatriel]

What would a project give us?

[erlend-aasland]

IMO¹, it is easier to break a large pile of issues into smaller, more manageable pieces, mainly because of its grouping and filtering features, which are, in my opinion, superior to the filtering found in GitHub Issues.

IDLE has almost 300 issues; they are managed/triaged here: https://github.com/orgs/python/projects/31/

Footnotes

1. What works for me may not necessarily work out for others; this is just my personal opinion. ↩

[iritkatriel]

I've assigned this to everyone on the team because it's a collective effort.

The way I've been doing this is:

1. If the issue is still relevant, put a 3.12 label on it.
2. If it can be closed, close it.
3. If it's not really a performance issue, remove the performance label.
4. If I think it can be closed but not sure I ask a question and put a pending label (after a few weeks with no response we can close).

The link in the first comment of this issue excludes the 3.12 issues, so it shows only untriaged items.

[erlend-aasland]

The way I've been doing this is:

1. If the issue is still relevant, put a 3.12 label on it.

... and put a triaged label on it, I presume:

• Adding a new "validation" step to our issue handling workflow python/steering-council#130

[iritkatriel]

The way I've been doing this is:

1. If the issue is still relevant, put a 3.12 label on it.

... and put a triaged label on it, I presume:

No, I haven't been doing that.

[eendebakpt]

@iritkatriel There are also several performance related PRs that do not have the performance label. I performed a search on github using is:pr is:open optimize -label:performance and is:pr is:open performance -label:performance and hand selected the PRs that (in my opinion) could be either added to the 3.12+ performance related PRs or closed.
There are 16 of them, the links are included in the details below.

31-8-2022 potential performance PRs:

• gh-91539: improve performance of get_proxies_environment  python/cpython#91566
• GH-91166: zero copy SelectorSocketTransport transport implementation python/cpython#31871
• bpo-46564: Optimize super().meth() calls via adaptive superinstructions python/cpython#30992
• bpo-45542: Improve performance of comparison operators python/cpython#29109
• bpo-44850: Improve the performance of methodcaller. python/cpython#27782
• bpo-39102: Increase Enum performance up to 10x times (3x average) python/cpython#17669
• bpo-37907: Slightly improve performance of PyLong_AsSsize_t() with large longs python/cpython#15363
• bpo-25433: Align bytearray strip methods to those found in byteobject.c python/cpython#14771
• gh-86620: Optimize constant slice creation python/cpython#23496
• bpo-46939: Specialize calls to Python classes (POSTCALL edition) python/cpython#31936
• gh-91851: Micro optimizations for Fraction's arithmetic python/cpython#25518
• bpo-28307: Optimize C-style formatting of numbers python/cpython#26160
• bpo-37371: Optimize and refactor readline(). python/cpython#14306
• bpo-39783: Optimize contruction of Path and PurePath objects python/cpython#20288
• bpo-13451: Optimize sched.scheduler.cancel() python/cpython#22759
• gh-85160: Optimized singledispatchmethod access (noticeable improvement). python/cpython#23213

[iritkatriel]

@eendebakpt Thanks for the list. I looked at a few and they seem related to open issues with the performance label, so they will be merged or closed when we look at those issues.

Perhaps the simplest way forward is to add the performance label to all those PRs, and then we will look at them just like we look at issues?

[eendebakpt]

@eendebakpt Thanks for the list. I looked at a few and they seem related to open issues with the performance label, so they will be merged or closed when we look at those issues.

Perhaps the simplest way forward is to add the performance label to all those PRs, and then we will look at them just like we look at issues?

Sounds good!

[gvanrossum]

Looks like someone added the "performance" label to the PRs found by @eendebakpt. The most inclusive query I can do is https://github.com/python/cpython/labels/performance which has 244 open issues.

How do I know which ones Irit hasn't already triaged? Only one of these has a 'triaged' label. 5 have 'pending'.

(I think Irit's original query was a tiny bit faulty, it excludes the three issues that have both 3.11 and 3.12 labels. Is the intention of the version labels to indicate the first version where the bug occurs?)

[iritkatriel]

The version labels are where we intend to fix the bug. It should be a version that has the issue and can still get the fix (at the time of labelling/relabelling).

I think it would be great to also have indication of where the bug was first observed, this was discussed during the GitHub migration but there is no convenient way to do this with labels so you need to figure it out from the issue’s history (comments and labels that have been removed). Thankfully the version labels were not removed altogether (that was suggested as well).

I filter on 3.12 because the purpose here is to review the old issues. Anything that has 3.12 on it was either recently created or recently triaged.

[iritkatriel]

Closing as complete.

Apart from 3 stdlib items that would require investigation by a subject matter expert, all the issues on the original list are now either closed or marked 3.12 or pending (i.e., we will decide one way or the other soon, based on responses).

Of the 243 items on the original list, we now have 150 marked performance that are left open. Most of the others were closed, though there were some that remained open but lost the "performance" label because it was not actually relevant.