[IronPython] Logging module

[Shri Borde]

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.

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: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] 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: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] 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
>> <fuzzyman at voidspace.org.uk> 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
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>   
>>     
>
>
>   


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


_______________________________________________
Users mailing list
Users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com