[issue44222] Improving _removeHandlerRef for a very long _handlerList

Change by Yonatan Goldschmidt : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ _

[issue44222] Improving _removeHandlerRef for a very long _handlerList

miss-islington added the comment: New changeset 156699bca02dd2def844d03e26fc16a831336635 by Yonatan Goldschmidt in branch 'main': bpo-44222: Improve _removeHandlerRef() for a very long _handlerList (GH-26325) https://github.com/python/cpython/commit/156699bca02dd2def844d03e26fc16a831336635

[issue44222] Improving _removeHandlerRef for a very long _handlerList

Yonatan Goldschmidt added the comment: That system has many (>10k) objects of a certain type. Each of them has a separate Logger object + Handlers. That was done, among other reasons, to allow for easy consuming of the logs relating to a particular object in a file-based manner. I agree tha

[issue44222] Improving _removeHandlerRef for a very long _handlerList

Vinay Sajip added the comment: Seems a bit of a pathological case - out of interest, why do you need to create tens of thousands of loggers and handlers? Each logger is supposed to represent an area of the application. If you want to track e.g. client IP requests or similar, there are better

[issue44222] Improving _removeHandlerRef for a very long _handlerList

Change by Yonatan Goldschmidt : -- keywords: +patch pull_requests: +24918 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26325 ___ Python tracker

[issue44222] Improving _removeHandlerRef for a very long _handlerList

New submission from Yonatan Goldschmidt : We have an application which creates 10,000s of logging.Logger & logging.Handler objects. I encountered a major slowdown during GCs which happen to collect dead Handler objects, calling logging._removeHandlerRef() along the way. That function looks li