[ 
https://issues.apache.org/jira/browse/LOG4NET-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dominik Psenner reopened LOG4NET-429:
-------------------------------------


Apologies. I've just run another 2 tests using a performance profiler that 
tracks the call stacks and it looks like your assumption is almost right. 
Whenever a patternlayout contains the property flag, the dictionary holding all 
properties is initialized as soon as the key is looked up. Therefore I've 
observed that the time is spent in LoggingEvent.CreatePompositeProperties(), 
invoked by LoggingEvent.LookupProperty(string key).

That's the good news. The bad news is that at the moment there's no way around 
this because the property keys are not organized in domains. I'll have to think 
about how we can work around this issue.

> Pattern with Context property causes severe slowdown
> ----------------------------------------------------
>
>                 Key: LOG4NET-429
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-429
>             Project: Log4net
>          Issue Type: Improvement
>          Components: Appenders
>    Affects Versions: 1.2.13
>            Reporter: Jonas Versén
>            Assignee: Dominik Psenner
>            Priority: Minor
>
> If you use a context property in your appenders pattern, there will be a 
> significant logging slowdown. In my experience anywhere from 3 to 5 times 
> slower (this will depend on the appender).
> I believe that as soon as you use a context property log4net will internally 
> access the windows user name even though it's not the property you want to 
> access. This theory comes from the fact that printing all properties in the 
> pattern (including the costly property username) compared to just printing 
> one will slow down the logging with the same factor.
> I've made a stackoverflow question with more details as well
> http://stackoverflow.com/questions/22612286/using-log4net-context-properties-has-negative-impact-on-performance/



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to