Skip to content

Optimize _PyObject_IS_GC in free-threaded build #114733

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

Open
colesbury opened this issue Jan 29, 2024 · 0 comments
Open

Optimize _PyObject_IS_GC in free-threaded build #114733

colesbury opened this issue Jan 29, 2024 · 0 comments
Labels
topic-free-threading type-feature A feature request or enhancement

Comments

@colesbury
Copy link
Contributor

colesbury commented Jan 29, 2024

Feature or enhancement

@nascheme writes the following suggestion (from #114564 (comment)):

_PyObject_IS_GC() could be optimized in the nogil build. That function is a bit expensive since it has to check for tp_is_gc() and possibly call it. Now that all objects have ob_gc_bits, we could store the "IS GC" status as another bit there, when the object is allocated.

I think this might require a bit of refactoring, but worth doing eventually. At a glance:

  • _PyObject_GC_New() (and related functions) could initialize ob_gc_bits with the "IS GC" set
  • PyType_GenericAlloc() would also need to initialize ob_gc_bits with the "IS GC" set if the type is a GC type.
  • _Py_NewReference() requires some care. It. currently initializes ob_gc_bits to zero and it's used after "allocating" objects from freelists.
@colesbury colesbury added type-feature A feature request or enhancement topic-free-threading labels Jan 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic-free-threading type-feature A feature request or enhancement
Projects
None yet
Development

No branches or pull requests

1 participant