ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Burgess, Benjamin" <>
Subject RE: AW: Adding a methof to StringUtils
Date Wed, 19 Apr 2006 18:44:55 GMT
A good description of this comes from the JavaDocs for Log4j here:

So actually, you would only wrap the debug log statement in an
if(log.isDebug()) if the message itself is more than a simple String
(ie. Contains concatenation or creates an object).


-----Original Message-----
From: Steve Loughran [] 
Sent: Wednesday, April 19, 2006 8:49 AM
To: Ant Developers List
Subject: Re: AW: Adding a methof to StringUtils

Kev Jackson wrote:
> wrote:
>>> As I've been hacking away today, I've been swapping a load of "" +
>>> + "" style code over to use StringBuffers.  I thought that perhaps 
>>> there's a potential use of a static method in StringUtils to 
>>> construct these strings from an array
>> For a significant performance boost we had to refactor the whole (or
>> major part) of the codebase in this manner. So I think a performance
>> test would be good. How much is the improvement on <delete>?
> It's less to do with speed performance and more to do with memory 
> performance.  "a" + "b" + "c" creates "a" + "bc" <- intermediate
> and then "abc"
> I'd love to do a performance/memory test of some kind, perhaps I'll
> the new NetBeans (it's supposed to have a good view of the heap being 
> used).  Any suggestions on tools to help evaluate changes would be
> We also have a problem with logging in general where the Strings are 
> concatenated :
> log("a" + toFile + " b " + dir + etc, verbosity);
> This will produce a lot of temp Strings, send the result to log and 
> crucially, if the verbosity is too low, won't even use it - that's a 
> waste of memory in every sense of the word.  I'd like to fix this, the

> appendMessage method I proposed is only a bandaid for now.
> Essentially we don't want to perform any operations, or produce any 
> temporary values if they aren't going to be used, but I can't see a
> of doing this without something like
> if (verbosity >= Project.MSG_INFO) {
>  log(msg + e + msg2);
> }
> but this is subverting the log method that uses the verbosity 
> internally, and adding conditions to the construction of log messages
> not nice.

This is the pattern you encounter with log4j/commons-logging a lot

if(log.isDebug() {

skipping the entire concat and log process would speed things up. Too 
bad the log interface spews everything out and then it gets discarded 
later. I think in the Ant1.8+ timeframe we could think about tuning how 
we log to let tasks find out more about how they get logged and feed 
that back in to string creation.

Regarding the change, I thought for a moment you were in Java5 varargs 
code. Whatever changes are used they should ideally prepare ant for a 
world where varargs logging is possible, some years down the line, or 
much closer in third party java5+ only tasks.


To unsubscribe, e-mail:
For additional commands, e-mail:

This message, including any attachments, contains confidential information intended for a
specific individual and purpose, and is protected by law.  If you are not the intended recipient,
please contact sender immediately by reply e-mail and destroy all copies.  You are hereby
notified that any disclosure, copying, or distribution of this message, or the taking of any
action based on it, is strictly prohibited.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message