Look at the source code for Thread.getStackTrace(). When this == currentThread(), it calls new Exception().getStackTrace(). Less indirection to just do it directly. ;)
On 30 March 2017 at 10:16, Ralph Goers <[email protected]> wrote: > I should note that in Java 9 getting the location information will be much > faster. > > Ralph > > > On Mar 30, 2017, at 7:44 AM, Pietro Galassi <[email protected]> > wrote: > > > > Perfect. > > > > So using a method that will add location information on demand is the > best > > choice. This will let remove %M or the specific method finding logic > > whenever it's not necessary. > > > > Regards. > > > > > > > > On Thu, Mar 30, 2017 at 4:36 PM, Remko Popma <[email protected]> > wrote: > > > >> > >>> On Mar 30, 2017, at 21:51, Pietro Galassi <[email protected]> > >> wrote: > >>> > >>> Thanks a lot! > >>> > >>> So: > >>> > >>> - for class name better to use %c with the LogManager.getLogger(this. > >> class) > >>> instead of the calculation i do ? > >> Yes. > >>> > >>> - for method name avoid %M and use new Throwable().getStackTrace > instead > >>> Thread.currentThread().getStackTrace() to get better performance ? > >> I don't think you understand what I am trying to say. > >> > >> If you want good performance you need to give up on the idea of printing > >> location information. > >> > >> Not with %M, not with any custom logic, because *all* of these are slow. > >> > >> Why would you want location information? If you want to be able to look > at > >> a log message and understand where in the code it came from, then simply > >> use unambiguous log messages in your code. The %c will tell you the > class > >> name so you know which class to look at. Then just search for the log > >> message string in that class. > >> > >>> > >>> > >>> Regards > >>> > >>>> On Thu, Mar 30, 2017 at 1:49 PM, Remko Popma <[email protected]> > >> wrote: > >>>> > >>>> > >>>> > >>>> Sent from my iPhone > >>>> > >>>>> On Mar 30, 2017, at 16:24, Pietro Galassi <[email protected]> > >>>> wrote: > >>>>> > >>>>> So, > >>>>> > >>>>> using such code like this: > >>>>> > >>>>> LogManager.getLogger(this.class); will let the code be fast ? > >>>> Yes. > >>>>> > >>>>> > >>>>> and it's faster than the code i published ? > >>>> Yes. The point of my answer was that you want to *avoid calculating > >>>> location*. Just have log messages that clearly say "the result of step > >> X in > >>>> calculation Y is Z" and you don't need class name, method name or line > >>>> number in your log. > >>>>> > >>>>> > >>>>> Also why new Throwable().getStackTrace is faster than > >>>>> Thread.currentThread().getStackTrace(). ? > >>>> I think we concluded that from benchmarks results. We don't know why > >> they > >>>> are different. But anyway, the key to performance is avoiding all > >> attempts > >>>> to calculate location. > >>>> > >>>>> Does the new in Throwable can give performance issue ? > >>>> Yes. Avoid if you want good performance. > >>>>> > >>>>> > >>>>> Regards. > >>>>> > >>>>> > >>>>>> On Wed, Mar 29, 2017 at 5:49 PM, Remko Popma <[email protected] > > > >>>> wrote: > >>>>>> > >>>>>> Pietro, > >>>>>> > >>>>>> The performance impact of logging location information is massive. > >>>>>> See > >>>>>> https://logging.apache.org/log4j/2.x/performance.html# > >>>>>> asyncLoggingWithLocation > >>>>>> > >>>>>> You can increase logging speed by ~80x by not logging location > >>>> information. > >>>>>> > >>>>>> If you follow the conventions that each class has its own logger > (and > >>>> the > >>>>>> logger name is the class that it is for), then %c or %logger in the > >>>> pattern > >>>>>> layout will tell you the name of the class. Then all that remains is > >>>> make > >>>>>> your log messages informative enough that you don't need line > numbers > >> to > >>>>>> disambiguate them. > >>>>>> > >>>>>> Remko > >>>>>> > >>>>>> > >>>>>> On Thu, Mar 30, 2017 at 12:42 AM, Ralph Goers < > >>>> [email protected]> > >>>>>> wrote: > >>>>>> > >>>>>>> What Java version are you using? Why do you think your code is > going > >>>> to > >>>>>>> perform better than what Log4j is doing? > >>>>>>> > >>>>>>> The fastest way to get the caller information is to use Java 9’s > >>>>>>> StackWalker.getCallerClass() method which only takes a couple of > >>>>>>> milliseconds. But doing that might actually make the application > >>>> perform > >>>>>>> worse as you would potentially be capturing that information even > for > >>>>>>> events that are not going to be logged. > >>>>>>> > >>>>>>> Ralph > >>>>>>> > >>>>>>>> On Mar 29, 2017, at 3:42 AM, Pietro Galassi < > >> [email protected] > >>>>> > >>>>>>> wrote: > >>>>>>>> > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> sorry for boothering you all. I'm in the need to have a logging > >>>>>>>> optimization and i whould like to ask you all about the use of > %m%n. > >>>>>>>> > >>>>>>>> Due to the fact i need optimization should i use : > >>>>>>>> > >>>>>>>> %m%n > >>>>>>>> > >>>>>>>> or should implement my own Class/Method name finder with: > >>>>>>>> > >>>>>>>> > >>>>>>>> private static String getLoggingMethod() { > >>>>>>>> StackTraceElement stackTraceElements[] = Thread.currentThread(). > >>>>>>>> getStackTrace(); > >>>>>>>> StackTraceElement caller = stackTraceElements[3]; > >>>>>>>> return caller.getMethodName(); > >>>>>>>> } > >>>>>>>> > >>>>>>>> and > >>>>>>>> > >>>>>>>> > >>>>>>>> private String getLoggingMethodClassNameIfDebug(int deep) { > >>>>>>>> if (logger.isDebugEnabled()) { > >>>>>>>> StackTraceElement stackTraceElements[] = Thread.currentThread(). > >>>>>>>> getStackTrace(); > >>>>>>>> StackTraceElement caller = stackTraceElements[deep]; > >>>>>>>> return buildMehodNameClassNameByStackTrace(caller); > >>>>>>>> } else { > >>>>>>>> return EMPTY; > >>>>>>>> } > >>>>>>>> } > >>>>>>>> > >>>>>>>> > >>>>>>>> ? > >>>>>>>> > >>>>>>>> Thanks a lot in advice. > >>>>>>>> > >>>>>>>> Best regards, > >>>>>>>> Pietro > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> ------------------------------------------------------------ > >> --------- > >>>>>>> To unsubscribe, e-mail: [email protected] > >>>>>>> For additional commands, e-mail: log4j-user-help@logging. > apache.org > >>>>>>> > >>>>>>> > >>>>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: [email protected] > >>>> For additional commands, e-mail: [email protected] > >>>> > >>>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Matt Sicker <[email protected]>
