Skip to content

Unexpected scaling bottleneck in _PyType_Lookup / _PyType_LookupStackRefAndVersion #145685

Closed
Closed
Unexpected scaling bottleneck in _PyType_Lookup / _PyType_LookupStackRefAndVersion#145685
Labels
3.14bugs and security fixes3.15bugs and security fixesperformancePerformance or resource usagetopic-free-threadingtype-bugAn unexpected behavior, bug, or error

Description

@colesbury
colesbury
opened on Mar 9, 2026

Bug report

There are scaling bottlenecks in the slow paths of _PyType_LookupStackRefAndVersion(), and it turns out that these can be a major bottleneck in larger applications.

For context, I've been testing Zulip with 3.14t and multithreading. The problem is basically:

  1. There are a lot of attribute loads that are not monomorphic (so specialization is of limited help)
  2. There are lots of unique (type, attr) lookups, so there are frequent collisions in the global MRO cache

The slow path for this case acquires the global type lock.

We should avoid acquiring the global type lock if the type already has a valid version tag. We'll also want to avoid reference count contention on the MRO tuple.

Linked PRs

Activity

  1. colesbury
    added
    type-bugAn unexpected behavior, bug, or error
    topic-free-threading
    3.14bugs and security fixes
    3.15bugs and security fixes
    performancePerformance or resource usage
    on Mar 9, 2026
  2. colesbury
    added 8 commits that reference this issue on Mar 9, 2026

    pythongh-145685: Update find_name_in_mro() to return a _PyStackRef

    e4529ed

    pythongh-145685: Stop the world when updating MRO of existing types

    9a5bd48

    pythongh-145685: Update find_name_in_mro() to return a _PyStackRef

    0a8e9d9

    pythongh-145685: Stop the world when updating MRO of existing types

    8a48b86

    gh-145685: Stop the world when updating MRO of existing types (gh-145707

    0b65c88

    [3.14] pythongh-145685: Stop the world when updating MRO of existing …

    c2bbd7a

    [3.14] gh-145685: Stop the world when updating MRO of existing types (g…

    5402465

    gh-145685: Update find_name_in_mro() to return a _PyStackRef (gh-145693)

    f26eca7
  3. miss-islington
    added a commit that references this issue on Mar 10, 2026

    pythongh-145685: Update find_name_in_mro() to return a _PyStackRef (p…

    e28d08b
  4. colesbury
    added a commit that references this issue on Mar 10, 2026

    pythongh-145685: Improve scaling of type attribute lookups

    9d1b301

  5. 7 remaining items

  6. miss-islington
    added a commit that references this issue on Mar 12, 2026

    pythongh-145685: Improve scaling of type attribute lookups (pythongh-…

    1509eb7
  7. colesbury
    added a commit that references this issue on Mar 12, 2026

    [3.14] gh-145685: Improve scaling of type attribute lookups (gh-145774)…

    cedff2d

  8. khalidsaidi commented on Mar 25, 2026

    @khalidsaidi
    khalidsaidi
    on Mar 25, 2026 · Hidden as spam
  9. ljfp
    added 4 commits that reference this issue on Apr 25, 2026

    pythongh-145685: Stop the world when updating MRO of existing types (p…

    d073ae0

    pythongh-145685: Update find_name_in_mro() to return a _PyStackRef (p…

    a56003c

    pythongh-145685: Avoid contention on TYPE_LOCK in super() lookups (py…

    599f246

    pythongh-145685: Improve scaling of type attribute lookups (pythongh-…

    645d773
  10. kumaraditya303
    added a commit that references this issue on Jul 21, 2026

    gh-145685: per-type method cache implementation (#150160)

    daf09e1
  11. kumaraditya303
    closed this as completedon Jul 21, 2026

  12. maurycy commented on Aug 5, 2026

    @maurycy
    maurycy
    on Aug 5, 2026
    Contributor

    @colesbury @kumaraditya303 After daf09e1 _PySeqLock is not used anywhere anymore:

    maurycy@gimel cpython (main 9ccd5bb) % rg _PySeqLock
Objects/typeobject.c
11:#include "pycore_lock.h"          // _PySeqLock_*

Include/internal/pycore_lock.h
221:} _PySeqLock;
224:PyAPI_FUNC(void) _PySeqLock_LockWrite(_PySeqLock *seqlock);
227:PyAPI_FUNC(void) _PySeqLock_UnlockWrite(_PySeqLock *seqlock);
231:PyAPI_FUNC(void) _PySeqLock_AbandonWrite(_PySeqLock *seqlock);
234:PyAPI_FUNC(uint32_t) _PySeqLock_BeginRead(_PySeqLock *seqlock);
238:PyAPI_FUNC(int) _PySeqLock_EndRead(_PySeqLock *seqlock, uint32_t previous);
242:PyAPI_FUNC(int) _PySeqLock_AfterFork(_PySeqLock *seqlock);

Python/lock.c
579:void _PySeqLock_LockWrite(_PySeqLock *seqlock)
600:void _PySeqLock_AbandonWrite(_PySeqLock *seqlock)
607:void _PySeqLock_UnlockWrite(_PySeqLock *seqlock)
614:uint32_t _PySeqLock_BeginRead(_PySeqLock *seqlock)
625:int _PySeqLock_EndRead(_PySeqLock *seqlock, uint32_t previous)
640:int _PySeqLock_AfterFork(_PySeqLock *seqlock)

    Shall we remove it?

  13. colesbury commented on Aug 5, 2026

    @colesbury
    colesbury
    on Aug 5, 2026 via email
    ContributorAuthor

  14. maurycy commented on Aug 5, 2026

    @maurycy
    maurycy
    on Aug 5, 2026
    Contributor

    @colesbury #155243

  15. colesbury
    added a commit that references this issue on Aug 6, 2026

    gh-145685: Remove `_PySeqLock` that is not used anymore (gh-155243)

    d2f4649
  16. mbeijen
    added a commit that references this issue on Aug 14, 2026

    pythongh-145685: Remove `_PySeqLock` that is not used anymore (python…

    fddfd42
  17. matthiasgoergens
    added a commit that references this issue on Sep 27, 2026

    Inline the per-type method cache lookup on the default build

    fa7ed79
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    3.14bugs and security fixes3.15bugs and security fixesperformancePerformance or resource usagetopic-free-threadingtype-bugAn unexpected behavior, bug, or error

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions