About performance

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

About performance

Pietro Galassi
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
Reply | Threaded
Open this post in threaded view
|

Re: About performance

Matt Sicker
The %m%n pattern is just the formatted message and a new line. The %M
pattern is for method names. And the current algorithm for finding it is
about the same: <
https://github.com/apache/logging-log4j2/blob/master/log4j-core/src/main/java/org/apache/logging/log4j/core/impl/Log4jLogEvent.java#L632>,
though we're looking at the JDK9 APIs for this that make it a bit faster in
9+ as well.

On 29 March 2017 at 05:42, Pietro Galassi <[hidden email]> 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
>



--
Matt Sicker <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: About performance

Ralph Goers
In reply to this post by Pietro Galassi
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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: About performance

Remko Popma-2
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 <[hidden email]>
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 <[hidden email]>
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: About performance

Pietro Galassi
So,

using such code like this:

LogManager.getLogger(this.class); will let the code be fast ?


and it's faster than the code i published ?


Also why  new Throwable().getStackTrace is faster than
Thread.currentThread().getStackTrace(). ?
Does the new in Throwable can give performance issue ?


Regards.


On Wed, Mar 29, 2017 at 5:49 PM, Remko Popma <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>
> > 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: About performance

Remko Popma-2


Sent from my iPhone

> On Mar 30, 2017, at 16:24, Pietro Galassi <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>> 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 <[hidden email]>
>>> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: About performance

Pietro Galassi
Thanks a lot!

So:

- for class name better to use %c with the LogManager.getLogger(this.class)
instead of the calculation i do ?

- for method name avoid %M and use new Throwable().getStackTrace instead
Thread.currentThread().getStackTrace() to get better performance ?


Regards

On Thu, Mar 30, 2017 at 1:49 PM, Remko Popma <[hidden email]> wrote:

>
>
> Sent from my iPhone
>
> > On Mar 30, 2017, at 16:24, Pietro Galassi <[hidden email]>
> 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 <[hidden email]>
> 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 <
> [hidden email]>
> >> 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 <[hidden email]
> >
> >>> 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: [hidden email]
> >>> For additional commands, e-mail: [hidden email]
> >>>
> >>>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: About performance

Remko Popma-2

> On Mar 30, 2017, at 21:51, Pietro Galassi <[hidden email]> 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 <[hidden email]> wrote:
>>
>>
>>
>> Sent from my iPhone
>>
>>> On Mar 30, 2017, at 16:24, Pietro Galassi <[hidden email]>
>> 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 <[hidden email]>
>> 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 <
>> [hidden email]>
>>>> 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 <[hidden email]
>>>
>>>>> 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: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: About performance

Pietro Galassi
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 <[hidden email]> wrote:

>
> > On Mar 30, 2017, at 21:51, Pietro Galassi <[hidden email]>
> 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 <[hidden email]>
> wrote:
> >>
> >>
> >>
> >> Sent from my iPhone
> >>
> >>> On Mar 30, 2017, at 16:24, Pietro Galassi <[hidden email]>
> >> 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 <[hidden email]>
> >> 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 <
> >> [hidden email]>
> >>>> 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 <
> [hidden email]
> >>>
> >>>>> 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: [hidden email]
> >>>>> For additional commands, e-mail: [hidden email]
> >>>>>
> >>>>>
> >>>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: About performance

Ralph Goers
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 <[hidden email]> 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 <[hidden email]> wrote:
>
>>
>>> On Mar 30, 2017, at 21:51, Pietro Galassi <[hidden email]>
>> 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 <[hidden email]>
>> wrote:
>>>>
>>>>
>>>>
>>>> Sent from my iPhone
>>>>
>>>>> On Mar 30, 2017, at 16:24, Pietro Galassi <[hidden email]>
>>>> 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 <[hidden email]>
>>>> 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 <
>>>> [hidden email]>
>>>>>> 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 <
>> [hidden email]
>>>>>
>>>>>>> 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: [hidden email]
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: About performance

Matt Sicker
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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>
> wrote:
> >
> >>
> >>> On Mar 30, 2017, at 21:51, Pietro Galassi <[hidden email]>
> >> 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 <[hidden email]>
> >> wrote:
> >>>>
> >>>>
> >>>>
> >>>> Sent from my iPhone
> >>>>
> >>>>> On Mar 30, 2017, at 16:24, Pietro Galassi <[hidden email]>
> >>>> 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 <[hidden email]
> >
> >>>> 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 <
> >>>> [hidden email]>
> >>>>>> 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 <
> >> [hidden email]
> >>>>>
> >>>>>>> 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: [hidden email]
> >>>>>>> For additional commands, e-mail: log4j-user-help@logging.
> apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: [hidden email]
> >>>> For additional commands, e-mail: [hidden email]
> >>>>
> >>>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Matt Sicker <[hidden email]>