[slf4j-dev] [Bug 31] Varargs for Logger methods

[bugzilla-daemon at pixie.qos.ch]

http://bugzilla.slf4j.org/show_bug.cgi?id=31





--- Comment #83 from Joern Huxhorn <joern at 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.