Shri Borde wrote:
OK, looking closer, the try-except is in _log which is guarded by "if" checks.
So if logging is disabled, the try-except is not even executed, which is great.
_srcfile can still be set to None to disable the call altogether if it
becomes a performance burden.
Michael
If logging is enabled, I assume the logging stream is cached, and so it will
result in disk IO only when flushed, which could be relatively rare. Also, if
the logging module supports things like flushing on a background thread, using
a fixed-size in-memory cache for crash analysis, etc, flushing may never happen
on the main thread. So there may still be a perf concern. However, since I am
speculating at this point, I will revert to saying that the simpler solution
should be tried first (which you have), and worry about perf only when there is
specific data.
Thanks,
Shri
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Michael Foord
Sent: Tuesday, February 17, 2009 10:07 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Logging module
Shri Borde wrote:
The proposal is to catch the ValueError exception using a try-except in the log
function. Raising a ValueError is not going to be good for perf as exception
handling on the CLR is relatively slow and meant for really exceptional
circumstances. Ideally, the results of the first call will be cached. Normally,
I would not worry about perf without concrete data, but users may be calling
logging.log quite heavily with the assumption that it is fairly cheap.
Given that it probably writes to a stream isn't that going to be much
more expensive than catching an exception?
Michael
Thanks,
Shri
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Michael Foord
Sent: Tuesday, February 17, 2009 1:51 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Logging module
Dan Eloff wrote:
On Mon, Feb 16, 2009 at 6:01 PM, Michael Foord
<[email protected]> wrote:
Fair enough then. I'm just putting together a patch and will ask the guys on
Python-Dev if we can get it into Python 2.6. You'll have to help me remember
to pull it out once we have frames again!
I'd suggest that we don't pull it out. It'd make it an easier decision
for the python-devs for one, I can't imagine they'd be enthusiastic to
accept a temporary patch. But the main thing being that frame support
will likely cause serious performance depredation, which means it's
likely to be an optional feature, hence we'd need that check anyway.
And then there's always Jython, which, as far as I know, would need
the same check.
So what kind of condition could we use that works with Jython and
IronPython currently, that won't break when IronPython does introduce
frames support (regardless of whether or not it has been enabled?)
Maybe just wrap it in a try/except?:
try:
foo = sys._getframe(1)
except (ValueError, AttributeError): # for IronPython, Jython
foo = None
Assuming Jython raises an AttributeError, which I do not know to be the case.
The actual patch is much simpler:
http://bugs.python.org/issue5287
We just need to set _srcfile to None and it prevents logging from
calling _getframe at all.
I've posted the patch and asked the Python-dev guys to consider
including it in Python 2.6.
On a side note - anyone know where tlbimp gets installed on Vista64?
Michael
-Dan
_______________________________________________
Users mailing list
[email protected]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
_______________________________________________
Users mailing list
[email protected]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
