> 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.