Actually its not a performance thing w.r.t concat AFAIK.. Its a
performance thing w.r.t to a wasted string creation In our previous job
we use to have a ton of logDebug("Value emitted:...." + xyz); ...
Problem was that we had like 1000s of lines like this which forced the
vm to create 1000s of strings which were wasted.. Basically AFAIK jvm
does not create/load the string on to its string pool until it
encounters the need for that string the first time.. So if we wrapped
every log debug with isDebugEnabled jvm would never need to load the
string to its string pool if debug is not enabled...
I really hated doing this at my last job but as Zeus says it apparently
improved the performance since it did not load the wasted strings off to
its string pool...
Correct answer would be profiling the diff and seeing if it would really
make a big difference for us.. If its a matter of only a few strings
like 100s I would n't think it would make a big difference...
Partha
Jesus M. Rodriguez wrote:
On Wed, Mar 18, 2009 at 1:27 PM, Mike McCune <mmcc...@redhat.com> wrote:
Devan Goodwin wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 18 Mar 2009 11:57:00 -0400
Justin Sherrill <jsher...@redhat.com> wrote:
Might be a nice thing to do after the next fork for Sat. Having to
use log.isDebugEnabled() is ugly IMO and it'd be nice not to have to
do it where we don't have to.
I hate doing this too. I was gonna take issue with it as it's ugly and
seemed pretty silly until I googled and saw that it is best practice if
the statement is doing string contact.
This the rule I followed as well. Wrap the log.debug() in the if statement
only if it was doing string concatenation of variables in your method.
I'd rather have lots of nice debug statements and a performance hit than
people skipping adding logging to our classes because it looks ugly.
I'd propose you only wrap if you are doing a:
log.debug("something to debug: " + somevariable);
otherwise wrapping this:
if (log.isDebugEnabled()) {
log.debug("Some message");
}
is largely pointless.
StopWatch st = new StopWatch();
st.start();
for (int i = 0; i < 100000000; i++) {
log.debug("Some line of debug");
}
st.stop();
System.out.println("Time: " + st.getTime());
output is ~500ms for a hundred million executions. And this:
StopWatch st = new StopWatch();
st.start();
for (int i = 0; i < 100000000; i++) {
if (log.isDebugEnabled()) {
log.debug("Some line of debug");
}
}
st.stop();
System.out.println("Time: " + st);
is actually 600ms! The if statement actually costs more than the simple call
to log.debug()
Concatenation does cost ya ...
StopWatch st = new StopWatch();
String rand = TestUtils.randomString();
st.start();
for (int i = 0; i < 100000000; i++) {
log.debug("Some line of debug" + rand);
}
st.stop();
is actually around 12 seconds. Not horrible but could be bad if the strings
are large.
Ok I can live with the only wrap them if your doing calculations i.e.
concats, etc.
I wrap them all simply because it's easier for me to remember, but if we can be
consistent that's better.
jesus
_______________________________________________
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
_______________________________________________
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
