Message399548
> I think in any case we should benchmark this because this will affect *all*
> GC types if I understand correctly and the TS mechanism had shown slowdowns
> before
We definitely need to benchmark. I would guess that adding trashcan protection
to all GC types would not be a performance issue. We already had the macros
for some performance critical ones (frame, tuple, list, dict).
The performance hit will likely come as a result of adding a branch that
uses _PyType_IS_GC() to the DECREF code path. It means any time an object hits
zero refcount, we call _PyType_IS_GC() on it. Previously, we would just call
tp_dealloc.
Because of PEP 442, _PyType_IS_GC() checks not only a type flag but might also
call tp_is_gc. So, benchmarks will need to be done. We might get a small win
because the trashcan logic can be better optimized now that it's in a single
complied unit.
Small correction for my explaination above: if tp_dealloc gets called mutiple
times because of the trashcan, it is the code before the BEGIN macro that gets
called mutiple times. |
|
Date |
User |
Action |
Args |
2021-08-13 17:31:20 | nascheme | set | recipients:
+ nascheme, tim.peters, vstinner, pablogsal |
2021-08-13 17:31:19 | nascheme | set | messageid: <1628875879.97.0.51598895447.issue44881@roundup.psfhosted.org> |
2021-08-13 17:31:19 | nascheme | link | issue44881 messages |
2021-08-13 17:31:19 | nascheme | create | |
|