http://bugzilla.slf4j.org/show_bug.cgi?id=31 --- Comment #83 from Joern Huxhorn <joern@huxhorn.de> 2010-04-01 10:52:20 --- (In reply to comment #80)
An added bit of information. As part of my work on Log4j 2.0 I discovered that there is significant overhead in using varargs. The technique used by SLF4J of providing 1, 2, 3 parameters and then 3 + varargs reduces the overhead considerably. This was true even when there were no parameters being passed.
Can you provide some numbers concerning the "significant overhead"? I'm not in doubt about your findings, I'd just like to some values for further discussion. (In reply to comment #82)
I have no idea what the compiler is doing.
Well, I suppose it's really just creating and filling an the Object[] and the impact you are observing is only caused by that and subsequent GC of the array. I have no idea what other magic should happen.
I had a method
isEnabled(Level level, Marker marker, String msg, Object... args);
I was calling it as
isEnabled(level, marker, msg, null); [..]
Do you think it's really wise to use *everything* in the isEnabled(..) method? I thought the main reason for those methods is to be able to decide very quickly if something should not be logged. Anything beyond Level and Marker seems like overkill to me. Isn't it acceptable that more complex filtering logic is a bit more expensive (i.e. will happen after creation of an actual LoggingEvent) with the advantage that the simple case is faster?
Interestingly, just before working on this code I attended a talk by Joshua Bloch were he discussed something very similar. http://www.cs.umd.edu/class/fall2009/cmsc132H/slides/still-effective.pdf - See slide 27.
*sigh*, an interface like that kind of hurts my aesthetic feelings ;) but I suppose performance is more important here, especially in the case were logging ISN'T actually performed but canceled by prior checks. Where should we go from here? Should I extend my proposed interface by methods with up to 5 arguments? This will mostly invalidate point 3.) in comment #45 (the explicit Throwable would still vanish). Another interesting question would be: How likely is it that this changes in future JVMs (i.e. the performance of varargs is improved)? Is it reasonable to assume that this may get JITed away? (I know, taking a look into a crystal ball might not really help us here ;)) -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.