You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Tolle Krez <tk...@hotmail.com> on 2003/12/10 00:17:05 UTC
[OT] Log4J and Pre-Processor
Sorry for an off-topic post. I hope I will get an answer since this is a very active
mailing list.
I am using Log4J for logging in my current project with too many logging statements. I
wrap every logging statements with the isDebugEnabled(), isWarnEnabled(), etc. During
production , the logging level will be set to very minimum, and only critical errors will
be logged. But however, the boolean comparison statements (whether or not to log) will
be executed, which we feel will have a performance impact.
I would like to know if it is a good idea to pre-process the java code to remove all the
logging statements and then create the binary?? or to begin with, limit the number of
logging statements during the development process itself?? If pre-processing the source
code to find and remove logging statements.. is a better option, then can some one point
me to a good java pre processor?
Thanks in Advance.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: [OT] Log4J and Pre-Processor
Posted by Derek Clarkson <dc...@waterwerks.com.au>.
Of course having any extra statements in a program is going to cost in terms
of CPU time. The questions is how much. I have seen simple removeal of code,
as well as addition of code make massive differences to the time it costs to
run something. I have also seem it make no visible difference as well. The
trick is to run it both before and after the code changes so that you can
measure how big a change it is.
I would suggest do a run with the logging code in, and then one without. If
the difference is not great, then leave the code in as you never know when
you will need it. If there is a large difference then you have to decide how
important it really is.
cio
Derek.
On Wednesday 10 December 2003 10:17, Tolle Krez wrote:
> Sorry for an off-topic post. I hope I will get an answer since this is a
> very active mailing list.
>
> I am using Log4J for logging in my current project with too many logging
> statements. I wrap every logging statements with the isDebugEnabled(),
> isWarnEnabled(), etc. During production , the logging level will be set to
> very minimum, and only critical errors will be logged. But however, the
> boolean comparison statements (whether or not to log) will be executed,
> which we feel will have a performance impact.
>
> I would like to know if it is a good idea to pre-process the java code to
> remove all the logging statements and then create the binary?? or to begin
> with, limit the number of logging statements during the development process
> itself?? If pre-processing the source code to find and remove logging
> statements.. is a better option, then can some one point me to a good java
> pre processor?
>
> Thanks in Advance.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
--
Regards,
Derek Clarkson
.O. Analyst/Programmer
..O Waterwerks Pty Ltd
OOO Melbourne, Australia
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: [OT] Log4J and Pre-Processor
Posted by Ted Husted <hu...@apache.org>.
You might first run some load tests to see if the boolean statements do
have a non-negligable performance impact. It's easy to loose something
like this in the rounding, and there may be better places to spend your
optimization dollars. As scientists, we should should more than "feel",
we should know.
Tolle Krez wrote:
> Sorry for an off-topic post. I hope I will get an answer since this is a very active
> mailing list.
>
> I am using Log4J for logging in my current project with too many logging statements. I
> wrap every logging statements with the isDebugEnabled(), isWarnEnabled(), etc. During
> production , the logging level will be set to very minimum, and only critical errors will
> be logged. But however, the boolean comparison statements (whether or not to log) will
> be executed, which we feel will have a performance impact.
>
> I would like to know if it is a good idea to pre-process the java code to remove all the
> logging statements and then create the binary?? or to begin with, limit the number of
> logging statements during the development process itself?? If pre-processing the source
> code to find and remove logging statements.. is a better option, then can some one point
> me to a good java pre processor?
>
> Thanks in Advance.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: [OT] Log4J and Pre-Processor
Posted by Kirk Wylie <kw...@m7.com>.
Tim Lucia wrote:
> Would you rather have that 5ns, or the ace-in-the-hole where you can
> debug your app in an installed production environment by turning on
> (assuming you don't use the final static boolean method) the appropriate
> logger? This has been extremely helpful in debugging. It also catches
> lots of things you wouldn't ordinarily see, like when you add this to an
> ActionListener more then once and you see your actionPerformed() get
> called more then once. It's also useful for profiling.
I think my original email should make it abundantly clear on which side
_I_ fall on this issue. :-)
In fact, I've been known to (gasp! horror!) deploy applications into
production with "-g" enabled in order to be able to actually turn on
with java debugging enabled and remote debug the application (on an
unactive node, of course) in the production environment. I've heard of
people who just start their app servers with JDWP enabled all the time
for this reason, but I've never actually met one. :-)
In short, I've found that trying to save micro-amounts of time here and
there in an application at the expense of debuggability and
maintainability usually end up with a bad application that's also slow.
Java enterprise/web applications are so seldom, in my experience,
performance limited by the actual Java bytecode execution speed, as to
make optimizing for that virtually irrelevant. There are so many other
places to start optimizing rather than worrying about 5ns here and 5ns
there, particularly before you go into production and know that you
aren't suitably performant.
Kirk Wylie
M7 Corporation
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Log4J
Posted by Sathish Babu K R <kr...@yahoo.com>.
hi all
i m getting this error...
java.lang.NoClassDefFoundError:
org/apache/log4j/Category
at
com.pronto.web.AccessSummaryReportForm.validate(Unknown
Source)
at
org.apache.struts.action.ActionServlet.processValidate(ActionServlet.java:2106)
at
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1565)
at
org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:510)
at
javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at
javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at com.evermind[Oracle9iAS (9.0.4.0.0) Containers for
J2EE].server.http.ResourceFilterChain.doFilter(ResourceFilterChain.java:65)
at
oracle.security.jazn.oc4j.JAZNFilter.doFilter(JAZNFilter.java:293)
at com.evermind[Oracle9iAS (9.0.4.0.0) Containers for
J2EE].server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:602)
at com.evermind[Oracle9iAS (9.0.4.0.0) Containers for
J2EE].server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:308)
at com.evermind[Oracle9iAS (9.0.4.0.0) Containers for
J2EE].server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:779)
at com.evermind[Oracle9iAS (9.0.4.0.0) Containers for
J2EE].server.http.HttpRequestHandler.run(HttpRequestHandler.java:264)
at com.evermind[Oracle9iAS (9.0.4.0.0) Containers for
J2EE].server.http.HttpRequestHandler.run(HttpRequestHandler.java:107)
at com.evermind[Oracle9iAS (9.0.4.0.0) Containers for
J2EE].util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:192)
at java.lang.Thread.run(Thread.java:484)
pls tell me y?
sathish
__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
RE: [OT] Log4J and Pre-Processor
Posted by Tim Lucia <ti...@yahoo.com>.
Would you rather have that 5ns, or the ace-in-the-hole where you can
debug your app in an installed production environment by turning on
(assuming you don't use the final static boolean method) the appropriate
logger? This has been extremely helpful in debugging. It also catches
lots of things you wouldn't ordinarily see, like when you add this to an
ActionListener more then once and you see your actionPerformed() get
called more then once. It's also useful for profiling.
The biggest savings with if (logger.isDebugEnabled()) { } comes when the
logger generates lots of StringBuffer objects, costing memory and
garbage collection, which will significantly impact performance more
then the if () to check whether to do it or not.
Tim Lucia
> -----Original Message-----
> From: Kirk Wylie [mailto:kwylie@m7.com]
> Sent: Tuesday, December 09, 2003 7:20 PM
> To: Struts Users Mailing List
> Subject: Re: [OT] Log4J and Pre-Processor
>
> [snip]
> But do you really care that much about 5ns? Are you SURE you
> care that
> much about 5ns?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: [OT] Log4J and Pre-Processor
Posted by Kirk Wylie <kw...@m7.com>.
Tolle Krez wrote:
> I am using Log4J for logging in my current project with too many logging
> statements. I
> wrap every logging statements with the isDebugEnabled(),
> isWarnEnabled(), etc. During
> production , the logging level will be set to very minimum, and only
> critical errors will
> be logged. But however, the boolean comparison statements (whether or
> not to log) will
> be executed, which we feel will have a performance impact.
You're probably wrong.
http://jakarta.apache.org/log4j/docs/index.html
Their benchmark is 5nanoseconds to do that method call to determine if a
particular logging level is enabled. If you're THAT concerned about 5ns,
your program probably has such hard performance requirements that you
designed first around performance to begin with, no?
> I would like to know if it is a good idea to pre-process the java code
> to remove all the
> logging statements and then create the binary?? or to begin with, limit
> the number of
> logging statements during the development process itself?? If
> pre-processing the source
> code to find and remove logging statements.. is a better option, then
> can some one point
> me to a good java pre processor?
Don't bother. For this, you can rely on public static final boolean
member variables.
Basically, if you compile with any type of optimization on, any call
that is like this:
if(false) {
}
will be optimized away entirely (i.e. the bytecodes won't even appear in
the .class file at all). That also flows through variables:
public class Debug {
public static final boolean DEBUG_LEVEL = false;
}
public class Foobar {
public void doStuff() {
if(Debug.DEBUG_LEVEL) {
// This can never happen and won't
// be in the bytecodes.
}
}
}
So if you care THAT much about 5ns per call, do it this way (through
compilation) and let the java compiler do the work for you. For this,
even if you decide to pre-process, you don't have to pre-process.
But do you really care that much about 5ns? Are you SURE you care that
much about 5ns?
Kirk Wylie
M7 Corporation
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org