Seemingly there is eeny-weeny little things what could be optimized in Log4J.
Re: Proposed synchronization changes
log4j-dev
Re: log4j multithreading performance
Proposed synchronization changes
By quickly looking, changes make sense, only one detail strikes me as potential problem: new logic is causing re-allocation of StringBuffer iin PatternLayout, everytime when formatting of layout is done (== every logged event). That may cause undesired gc behaviour in young generation.
References
Log4J
Update: 1.6.2011
If starting logging now, better to consider successor of Log4j Logback. Compared to Log4J, Logback offers some optimizations, like reduced overhead in ”isDebugEnabled()” checks (19ns vs. 10ns), however, that difference isn’t as drastic as you think, unless you’ve placed debug traces inside very tight loop (which anyways, isn’t adviseable). So performance benefit on that case isn’t reason to switch. Additionally, Logback supports special ”parametrized debug call”, which seems to be performance wise in the range of Log4J performance with ”isDebugEnabled()”. However, after investigating more deeply, this ”parametrized” logging API isn’t as marvellous as you think, since it has showstopper problems. Namely, it doesn’t support varargs (one arg, 2 args, Object[], that can be real nuisance), and also it doesn’t work at all, if you want to trace exception (this is clear showstopper). So it’s sounds more like API, which would have required more thought before publishing it. At cons side, Logback has also lost convenient properties file based configuration API.