Vinay Sajip vinay_sa...@yahoo.co.uk 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
William Hart whart...@gmail.com 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
William Hart whart...@gmail.com 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 rep...@bugs.python.org wrote:
Vinay Sajip
Vinay Sajip vinay_sa...@yahoo.co.uk 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
William Hart whart...@gmail.com 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
Vinay Sajip vinay_sa...@yahoo.co.uk 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
Vinay Sajip vinay_sa...@yahoo.co.uk 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
New submission from William Hart whart...@gmail.com:
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
Changes by Ned Deily n...@acm.org:
--
nosy: +vinay.sajip
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11369
___
___
Python-bugs-list mailing list
