Triage the open "performance" issues on cpython repo #440

Activity

1. erlend-aasland commented on Aug 1, 2022

   

   erlend-aasland

   on Aug 1, 2022

   More actions

   Create a GH Project for it so it is easier to break it into smaller, manageable pieces.
2. iritkatriel commented on Aug 1, 2022

   

   iritkatriel

   on Aug 1, 2022

   CollaboratorAuthor

   More actions

   What would a project give us?
3. erlend-aasland commented on Aug 1, 2022

   

   erlend-aasland

   on Aug 1, 2022

   Last edited by erlend-aasland

   More actions

   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: IDLE Issues

   Footnotes

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

   👍React with 👍1Reacted by Leandro de Oliveira
4. gvanrossum

   changed the title [-]Triage the open "performance" issue on cpython repo[/-] [+]Triage the open "performance" issues on cpython repo[/+] on Aug 1, 2022
5. iritkatriel

   moved this from Todo to In Progress in Fancy CPython Boardon Aug 30, 2022
6. iritkatriel

   assigned

   lpereira

   ,

   mdboom

   ,

   iritkatriel

   ,

   ericsnowcurrently

   ,

   gvanrossum

   and

   brandtbucher

   on Aug 30, 2022
7. iritkatriel commented on Aug 30, 2022

   

   iritkatriel

   on Aug 30, 2022

   CollaboratorAuthor

   More actions

   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.
8. erlend-aasland commented on Aug 30, 2022

   

   erlend-aasland

   on Aug 30, 2022

   More actions

   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
9. iritkatriel commented on Aug 30, 2022

   

   iritkatriel

   on Aug 30, 2022

   CollaboratorAuthor

   More actions

   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.

   😕React with 😕1Reacted by Erlend E. Aasland
10. eendebakpt commented on Aug 31, 2022

    

    eendebakpt

    on Aug 31, 2022

    Last edited by iritkatriel

    More actions

    @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
    • gh-72494: 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
    • gh-57660: Optimize sched.scheduler.cancel() python/cpython#22759
    • gh-85160: Optimized singledispatchmethod access (noticeable improvement). python/cpython#23213

    👍React with 👍3Reacted by Irit Katriel, Eric Snow and Yichen Yan
11. iritkatriel commented on Aug 31, 2022

    

    iritkatriel

    on Aug 31, 2022

    CollaboratorAuthor

    More actions

    @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?

    👍React with 👍1Reacted by Eric Snow
12. eendebakpt commented on Aug 31, 2022

    

    eendebakpt

    on Aug 31, 2022

    More actions

    @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!
13. gvanrossum commented on Sep 1, 2022

    

    gvanrossum

    on Sep 1, 2022

    Collaborator

    More actions

    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?)
14. iritkatriel commented on Sep 1, 2022

    

    iritkatriel

    on Sep 1, 2022

    CollaboratorAuthor

    More actions

    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.
15. iritkatriel commented on Sep 14, 2022

    

    iritkatriel

    on Sep 14, 2022

    CollaboratorAuthor

    More actions

    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.
16. iritkatriel

    closed this as completedon Sep 14, 2022
17. Repository owner moved this from In Progress to Done in Fancy CPython Boardon Sep 14, 2022