threading
primitives are subject to reference count contention
#134761
Labels
interpreter-core
(Objects, Python, Grammar, and Parser dirs)
performance
Performance or resource usage
topic-free-threading
type-feature
A feature request or enhancement
Uh oh!
There was an error while loading. Please reload this page.
Feature or enhancement
Proposal:
On the free-threaded build,
threading
's concurrency primitives have a bunch of extra overhead across multiple threads due to reference count contention. For example:vs
Comparing the two on a 3.15t release build:
That's a ~90% slowdown solely due to reference count contention.
We can significantly reduce this overhead by enabling deferred reference counting on these objects. This is already done for
threading.local
, but we can also do this forLock
andRLock
. It would also be nice to do this for primitives likeEvent
, so that will require a (private) API to expose DRC into Python.Has this already been discussed elsewhere?
This is a minor feature, which does not need previous discussion elsewhere
Links to previous discussion of this feature:
N/A
Linked PRs
threading
concurrency primitives #134762The text was updated successfully, but these errors were encountered: