You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[mypyc] Reduce impact of immortality on reference counting performance (#18459)
Fixesmypyc/mypyc#1044.
The addition of object immortality in Python 3.12 (PEP 683) introduced
an extra immortality check to incref and decref operations. Objects with
a specific reference count are treated as immortal, and their reference
counts are never updated.
It turns out that this slowed down the performance of certain workloads
a lot (up to 70% increase in runtime, compared to 3.11). This PR reduces
the impact of immortality via a few optimizations:
1. Assume instances of native classes and list objects are not immortal
(skip immortality checks).
2. Skip incref of certain objects in some contexts when we know that
they are immortal (e.g. avoid incref of `None`).
The second change should be clear. We generally depend on CPython
implementation details to improve performance, and this seems safe to do
here as well.
The first change could turn immortal objects into non-immortal ones. For
native classes this is a decision we can arguably make -- native classes
don't properly support immortality, and they can't be shared between
subinterpreters. As discussed in PEP 683, skipping immortality checks
here is acceptable even in cases where somebody tries to make a native
instance immortal, but this could have some performance or memory use
impact. The performance gains make this a good tradeoff.
Since lists are mutable, they can't be safely shared between
subinterpreters, so again not dealing with immortality is acceptable. It
could reduce performance in some use cases by deimmortalizing lists, but
this potential impact seems marginal compared to faster incref and
decref operations on lists, which are some of the more common objects in
Python programs.
This speeds up self check by about 1.5% on Python 3.13. This speeds up
the richards benchmark by 30-35% (!) on 3.13, and also some other
benchmarks see smaller improvements.
0 commit comments