Hi,
I see Jason has already scanned the patch.
Read his comment.
Basically
log.debug("some string");
doesn't need to be guarded, in fact it is slower
doing the guard.
It is only
log.debug("some string" + x);
because this has to create a StringBuffer.
Sorry this thread didn't explain that.
Regards,
Adrian
Me again,
I'll use your patch as a basis for doing this,
since you've already found the locations of the
unguarded debug calls.
Regards,
Adrian
Hi,
That's made some difference.
Here's a rough guide each from a single run of the
testsuite on my machine.
With debug turned on:
Before the changes 1420 secs
After the changes 1360 secs
With debug turned off:
Before the changes 1360 secs
After the changes 1280 secs
These are very rough figures, any real difference
is almost certainly swamped by the testsuite's
logging.
The biggest gain is likely to come from
moving log.info and System.out logging to
log.debug.
The difference with debug turned on can be explained
by changes to code that did
if (log.isDebugEnabled())
log.debug()
...
if (log.isDebugEnabled())
log.debug()
...
if (log.isDebugEnabled())
log.debug()
to
boolean debug = log.isDebugEnabled();
if (debug)
log.debug()
...
if (debug)
log.debug()
...
if (debug)
log.debug()
and similarly for loops.
In fact from the numbers above this may account for
most of the change. But this needs a better bench
test than the testsuite.
I've committed the changes.
I haven't broken anything :-)
Regards,
Adrian
Thanks for all the useful info. I now know more than before...
Scott Sanders
Thanks for your patch.
It made it a lot easier.
I only found one place where you might have
introduced a bug, except for Info.
What happened there? :-)
Thanks again,
Adrian