Neil Schemenauer <nas-pyt...@arctrix.com> added the comment:
> 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue44881> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
