[issue11369] Add caching for the isEnabledFor() computation

William Hart added the comment: Understood! FYI, we worked around this caching issue explicitly in our code. This wound up being simpler than supporting a hacked version of the logger. Thanks for looking into this! On Mon, Apr 11, 2011 at 1:54 AM, Vinay Sajip wrote: > > Vinay Sajip added

[issue11369] Add caching for the isEnabledFor() computation

Vinay Sajip added the comment: I'll regretfully have to mark this as wontfix, since adding threading interlocks for correct operation in multi-threaded environments will negate the performance benefit. -- resolution: -> wont fix status: open -> closed ___

[issue11369] Add caching for the isEnabledFor() computation

William Hart added the comment: Vinay: No, I haven't tried this in multi-threaded applications. You're correct that this would require locks around the global data. --Bill On Thu, Mar 10, 2011 at 3:16 AM, Vinay Sajip wrote: > > Vinay Sajip added the comment: > > Bill, > > I was looking at

[issue11369] Add caching for the isEnabledFor() computation

Vinay Sajip added the comment: Bill, I was looking at this patch again, and I'm not sure about thread safety. The correctness of the caching depends on manager.status, which is state which is potentially shared across threads. There are no interlocks around it, so with the patch as it stands

[issue11369] Add caching for the isEnabledFor() computation

Vinay Sajip added the comment: > I had somewhat shallow logger hierarchies (3-4 deep). The real problem was> >that this was being called in a kernel of my code ... so even that > additional cost was noteworthy. > > I think it's smart to focus on Python 3.3. As it happens, my colleagues di

[issue11369] Add caching for the isEnabledFor() computation

William Hart added the comment: Vinay: Yes, the bulk of the time was spent in getEffectiveLevel(). Since that method is only called by isEnabledFor(), it made sense to cache isEnabledFor(). But, that probably reflects the characteristics of my use of logging. I never call getEffectiveLevel()

[issue11369] Add caching for the isEnabledFor() computation

Vinay Sajip added the comment: Bill, Thanks for the suggestion and the patch. It's a good idea, though I wonder whether you found that the bulk of the time spent in isEnabledFor() was actually spent in getEffectiveLevel()? That's the one which loops through a logger's ancestors looking for a

[issue11369] Add caching for the isEnabledFor() computation

Changes by Ned Deily : -- nosy: +vinay.sajip ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue11369] Add caching for the isEnabledFor() computation

New submission from William Hart : I recently started using logging extensively in the Coopr software, and I ran into some performance issues when logging was used within frequently used kernels in the code. After profiling, it became clear that the performance of the logging package could be