You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@logging.apache.org by "Trenton D. Adams" <tr...@athabascau.ca> on 2005/11/28 04:41:40 UTC
taking advantage of JDK enhancements
Hi everyone,
I'm just curious if you guys think it would be beneficial to provide
factories for various objects in the log4j project, so that one could
choose to use the new objects, in the event they use a newer version of
java. Or, even auto detect the newer version of java, and use them
automatically.
For instance. I noticed that LocationInfo gets the location information
by parsing the output of the strack trace. In java 1.4, there is
something called "StackTraceElement", which has all of this information.
The throwable object can give this to you. The time it takes is
significantly less than log4j's parsing. I did a loop of 1M, logging a
simple line of text each time. Printing out the stack trace info, such
as line number, took about 0.06ms, whereas it took 0.3ms with log4j.
So, it took approximately 60 seconds to run through the whole loop. Not
printing it took 30 seconds. Given the extremely high performance of
this method of obtaining stack trace info, I use it in all of my logs. :)
Here's an example.
Logger logger;
Throwable th;
StackTraceElement[] ste;
th = new Throwable();
ste = th.getStackTrace();
if (ste.length == 0)
{
// no stack trace -- bad
logger = AGeneralStatic.logger;
}
else
{
int idx = 0;
if (ste.length > 2)
{
idx = 2;
}
logger = LogManager.getLogger(ste[idx].getClassName() + "." +
ste[idx].getMethodName());
}
So, instantiating LocationInfo through a factory would definitely be
beneficial, as you could simply instantiate different objects based on
the JDK that is currently running. Then, all I have to do to get line
numbers is add the %L, and wham, I've got them with very high performance.
__
This communication is intended for the use of the recipient to whom it
is addressed, and may contain confidential, personal, and or privileged
information. Please contact us immediately if you are not the intended
recipient of this communication, and do not copy, distribute, or take
action relying on it. Any communications received in error, or
subsequent reply, should be deleted or destroyed.
---
Re: taking advantage of JDK enhancements
Posted by "Trenton D. Adams" <tr...@athabascau.ca>.
Oh, that's the alpha version, that's why I didn't know about it. :)
The roadmap says 1.3 is supposed to be released in October. Any idea
when it will be released?
Thanks for the info.
Ceki Gülcü wrote:
>
> Trenton,
>
> Thank you for taking the time to share your idea. Log4j 1.3 already uses
> StackTraceElement when available. Please see
> http://svn.apache.org/viewcvs.cgi/logging/log4j/trunk/src/java/org/apache/log4j/spi/location/
> for more details.
>
> At 04:41 AM 11/28/2005, Trenton D. Adams wrote:
>
>> Hi everyone,
>>
>> I'm just curious if you guys think it would be beneficial to provide
>> factories for various objects in the log4j project, so that one could
>> choose to use the new objects, in the event they use a newer version
>> of java. Or, even auto detect the newer version of java, and use them
>> automatically.
>>
>> For instance. I noticed that LocationInfo gets the location
>> information by parsing the output of the strack trace. In java 1.4,
>> there is something called "StackTraceElement", which has all of this
>> information. The throwable object can give this to you. The time it
>> takes is significantly less than log4j's parsing. I did a loop of 1M,
>> logging a simple line of text each time. Printing out the stack trace
>> info, such as line number, took about 0.06ms, whereas it took 0.3ms
>> with log4j. So, it took approximately 60 seconds to run through the
>> whole loop. Not printing it took 30 seconds. Given the extremely
>> high performance of this method of obtaining stack trace info, I use
>> it in all of my logs. :)
>>
>> Here's an example.
>> Logger logger;
>> Throwable th;
>> StackTraceElement[] ste;
>>
>> th = new Throwable();
>> ste = th.getStackTrace();
>>
>> if (ste.length == 0)
>> {
>> // no stack trace -- bad
>> logger = AGeneralStatic.logger;
>> }
>> else
>> {
>> int idx = 0;
>> if (ste.length > 2)
>> {
>> idx = 2;
>> }
>> logger = LogManager.getLogger(ste[idx].getClassName() + "." +
>> ste[idx].getMethodName());
>> }
>>
>> So, instantiating LocationInfo through a factory would definitely be
>> beneficial, as you could simply instantiate different objects based on
>> the JDK that is currently running. Then, all I have to do to get line
>> numbers is add the %L, and wham, I've got them with very high
>> performance.
>>
>> __ This communication is intended for the use of the recipient to
>> whom it
>> is addressed, and may contain confidential, personal, and or
>> privileged
>> information. Please contact us immediately if you are not the intended
>> recipient of this communication, and do not copy, distribute, or take
>> action relying on it. Any communications received in error, or
>> subsequent reply, should be deleted or destroyed.
>> ---
>
>
Re: taking advantage of JDK enhancements
Posted by Ceki Gülcü <ce...@qos.ch>.
Trenton,
Thank you for taking the time to share your idea. Log4j 1.3 already uses
StackTraceElement when available. Please see
http://svn.apache.org/viewcvs.cgi/logging/log4j/trunk/src/java/org/apache/log4j/spi/location/
for more details.
At 04:41 AM 11/28/2005, Trenton D. Adams wrote:
>Hi everyone,
>
>I'm just curious if you guys think it would be beneficial to provide
>factories for various objects in the log4j project, so that one could
>choose to use the new objects, in the event they use a newer version of
>java. Or, even auto detect the newer version of java, and use them
>automatically.
>
>For instance. I noticed that LocationInfo gets the location information
>by parsing the output of the strack trace. In java 1.4, there is
>something called "StackTraceElement", which has all of this
>information. The throwable object can give this to you. The time it
>takes is significantly less than log4j's parsing. I did a loop of 1M,
>logging a simple line of text each time. Printing out the stack trace
>info, such as line number, took about 0.06ms, whereas it took 0.3ms with
>log4j. So, it took approximately 60 seconds to run through the whole
>loop. Not printing it took 30 seconds. Given the extremely high
>performance of this method of obtaining stack trace info, I use it in all
>of my logs. :)
>
>Here's an example.
> Logger logger;
> Throwable th;
> StackTraceElement[] ste;
>
> th = new Throwable();
> ste = th.getStackTrace();
>
> if (ste.length == 0)
> {
> // no stack trace -- bad
> logger = AGeneralStatic.logger;
> }
> else
> {
> int idx = 0;
> if (ste.length > 2)
> {
> idx = 2;
> }
> logger = LogManager.getLogger(ste[idx].getClassName() + "." +
> ste[idx].getMethodName());
> }
>
>So, instantiating LocationInfo through a factory would definitely be
>beneficial, as you could simply instantiate different objects based on the
>JDK that is currently running. Then, all I have to do to get line numbers
>is add the %L, and wham, I've got them with very high performance.
>
>__ This communication is intended for the use of the recipient to whom it
> is addressed, and may contain confidential, personal, and or privileged
> information. Please contact us immediately if you are not the intended
> recipient of this communication, and do not copy, distribute, or take
> action relying on it. Any communications received in error, or
> subsequent reply, should be deleted or destroyed.
>---
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
Improve your Sudoku skills at http://www.sudoku-grok.com/