http://bugzilla.slf4j.org/show_bug.cgi?id=163 --- Comment #29 from Joern Huxhorn <joern@huxhorn.de> 2010-03-30 17:06:57 --- (In reply to comment #28)
I suggest you run some performance tests. I am certain you are going to find that performance is very bad when logging is disabled as creating a Throwable on every call before doing any filtering is astronomically more expensive than just using a static string.
Again, I would suggest using a solution based on annotations. I know someone has already done it.
I also like the suggested annotation solution best since it does not have any downside I'm aware of. Unfortunately, I don't really know how to implement anything like it. It's pretty hard to benchmark code like the one in comment #27 without walking straight into some micro-benchmark trap. Any suggestions? I'm not sure if something like SimpleLogging above should really be included in SLF4J (or some extension jar) at all, I was merely playing around and wanted to share it. (most importantly, this shouldn't be considered a part of my SLF4J 2.0 proposal;)) However, I've just added another method, getCallingLogger(), that's returning either the logger of the calling class or a NOPLogger if such a logger could not be resolved (in case of Throwable.getStackTrace() returning an empty STE[]). This wouldn't have the likely big performance impact like the rest of the methods since it would only be called once while initializing the Logger. The code is again contained in http://github.com/huxi/slf4j/blob/slf4j-redesign/slf4j-n-api/src/main/java/o... and http://github.com/huxi/slf4j/blob/slf4j-redesign/slf4j-n-api/src/test/java/o... That method isn't really bad, I think. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.