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 getEffectiveLevel() otherwise, so caching
isEnabledFor() minimized the total cost of logging. I think you could
sensibly argue for caching getEffectiveLevel().
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 did
some explicit caching of logging information that made pyutilib.logging
redundant. When you don't think you need this as a reference
implementation, I'll delete it.
--Bill
On Wed, Mar 2, 2011 at 2:25 AM, Vinay Sajip <rep...@bugs.python.org> wrote:
>
> 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 ancestors looking for a level which is actually set, so intuitively
> it would take a while - especially for deeper levels in the logging
> hierarchy. If so (which I suspect to be the case, but it would be good to
> have you confirm it), a better solution may be to cache the effective level.
>
> Roughly how deep are/were your logger hierarchies in the situation where
> you experienced performance problems?
>
> I'm happy to look at caching effective level for Python 3.3: The 2.X
> branches are now closed for additions other than bugs and security issues.
>
> ----------
> assignee: -> vinay.sajip
>
> _______________________________________
> Python tracker <rep...@bugs.python.org>
> <http://bugs.python.org/issue11369>
> _______________________________________
>
----------
Added file: http://bugs.python.org/file20997/unnamed
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue11369>
_______________________________________
Vinay:<br><br>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() otherwise, so caching
isEnabledFor() minimized the total cost of logging. I think you could
sensibly argue for caching getEffectiveLevel().<br>
<br>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.<br><br>I think it's smart to focus on
Python 3.3. As it happens, my colleagues did some explicit caching of logging
information that made pyutilib.logging redundant. When you don't think
you need this as a reference implementation, I'll delete it.<br>
<br>--Bill<br><br><br><br><div class="gmail_quote">On Wed, Mar 2, 2011 at 2:25
AM, Vinay Sajip <span dir="ltr"><<a
href="mailto:rep...@bugs.python.org";>rep...@bugs.python.org</a>></span>
wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex;
border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Vinay Sajip <<a
href="mailto:vinay_sa...@yahoo.co.uk";>vinay_sa...@yahoo.co.uk</a>> added the
comment:<br>
<br>
Bill,<br>
<br>
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 level which is actually set, so
intuitively it would take a while - especially for deeper levels in the logging
hierarchy. If so (which I suspect to be the case, but it would be good to have
you confirm it), a better solution may be to cache the effective level.<br>
<br>
Roughly how deep are/were your logger hierarchies in the situation where you
experienced performance problems?<br>
<br>
I'm happy to look at caching effective level for Python 3.3: The 2.X
branches are now closed for additions other than bugs and security issues.<br>
<br>
----------<br>
assignee: Â -> vinay.sajip<br>
<br>
_______________________________________<br>
Python tracker <<a
href="mailto:rep...@bugs.python.org";>rep...@bugs.python.org</a>><br>
<<a href="http://bugs.python.org/issue11369";
target="_blank">http://bugs.python.org/issue11369</a>><br>
_______________________________________<br>
</blockquote></div><br>
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
