Skip to content

GH-132380: Add optimization for non-interned type lookup. #132652

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

Conversation

nascheme
Copy link
Member

@nascheme nascheme commented Apr 17, 2025

Add an optimized implementation of type lookup for names that are non-interned strings. This is only enabled for free-threaded builds since that kind of lookup can cause contention for the global type lock.

I benchmarked this with LibCST running on the numpy source code. Summary of results:

Config Time [s] Description
Base 38.1 Main branch of 3.13, free-threaded build
Non-interned lookup 24.1 With the version of this PR for 3.13 applied
GIL enabled 21.0 This is free-threaded build with GIL=1, uses multi-process
Python cache 27.2 This is with pr1295, using a Python-based cache on top of getattr()

The backport to 3.13 of this is non-trivial and so I made a separate PR for it (GH-132651). It is basically the same logic though. This approach to avoid the contention might be preferred to GH-132381 since I think it should be more obviously safe.

Benchmark results from pyperformance

Comment on lines +5743 to +5745
/* Keep a strong reference to mro because type->tp_mro can be replaced
during dict lookup, e.g. when comparing to non-string keys. */
mro = _PyType_GetMRO(type);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Won't this lead to reference count contention?

I don't think we need to skip the cache in this case. The names are exact unicode objects, they're just not interned. If the string isn't interned can we use a different loop in the lookup code that uses something like PyUnicode_Compare?

@nascheme
Copy link
Member Author

nascheme commented May 8, 2025

Closing since this is an approach we don't want to take.

@nascheme nascheme closed this May 8, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants