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
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:
>
> B
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
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
