>> Are the test programs identical? I Yes identical excepting for log4j versions and the required totally different way of configuring.
>> MDC Not coded this yet, wanting to in one version or the other. So no code to post since I haven't gotten to MDC vs NDC (??) yet. Just making sure going to v2 is doable perf-wise. We're short of CPU as it is in this env. :) Thanks for the help and opinions! BTW since you guys know the details well, we just need simple fish tagging, no location stuff, just a few context variables put into the context at event creation time on a thread, then all logs along that flow log 3-5 variables pulled from the context. Is this doable in v1 NDC?? I would just guess a name-value look up by name in the PatternLayout shouldn’t' be much of a perf hit??? curt -----Original Message----- From: Remko Popma [mailto:[email protected]] Sent: Tuesday, July 30, 2013 10:14 AM To: Log4J-Users List Subject: Re: reflection? RE: async logger on slow single core env performs 50% worse than log4j v1 It may be possible (but a bit of a hack) to use async loggers without reflection. It involves compiling your own version of the com.lmax.disruptor.util.Util class where you replace the implementation of the #getUnsafe() method with a simple call to sun.misc.Unsafe.getUnsafe(). Obviously this is not pretty and there are no guarantees that you won't get a SecurityException or so next... :-( You may be better off using AsyncAppender if you want your blocking I/O to happen in another thread. This may still be beneficial even on a one-core machine. Back to the difference between log4j-1.2 (20% CPU) and log4j-2.0 (40% CPU). Are the test programs identical? I remember you mentioned below that you use MDC with 2.0 but not with 1.2. Can you give a sample of your log4j usage with 1.2 and with 2.0? (Maybe create a JIRA and attach files to it?)
