geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Blewitt <>
Subject Re: [i18n] Hardcoded message strings
Date Thu, 21 Aug 2003 22:22:39 GMT
On Thursday, Aug 21, 2003, at 22:42 Europe/London, Bill de hÓra wrote:

> Alex Blewitt wrote:
>> My point was not the parse pattern itself; you'll note that in both 
>> examples it's there. What my point was is that there's very little 
>> point in building it up in memory using a StringBuffer, only to then 
>> write out the string as a whole, when you can write out the 
>> individual parts to the stream and get the concatenation for free.
>> IIRC the Java text classes parse the pattern and then build a string 
>> internally as a StringBuffer, then convert it to the string all in 
>> one go. My point was that it would be possible to write a log method 
>> that did not do that, but instead wrote it out to a stream in one go.
>> I can provide demo code if I'm not making the point clear :-)
> Alex,
> Totally clear. Does this not fall under the category of small 
> efficiencies tho'? That's assuming it is more efficient (I think it 
> might well be with a well-written lexer).

It's in the same category of efficiencies as using a StringBuffer 
instead of concatenating strings with +. In any case, it does solve the 
problems of doing a log(message) where message has been calculated 
above using string concatenation.

If you have log(String pattern,Object[] data) then it really doesn't 
matter whether you test for isLogEnabled first; the (relatively 
expensive) string concatenation doesn't occur until write time.

Speaking of small efficiencies, it's still amazing how many people use 
'println' to write out messages in a WebApp, even though println() is 

try {
} catch (IOException e) {
   // ignore

In fact, the only reason that Sun introduced PrintStreams in the first 
place (and the esteemed println method) was (a) they couldn't get the 
Unicode->ASCII thing right (some would say they still haven't :-) and 
(b) they didn't want to force people to do a 'try/catch' in the 
traditional 'Hello World' application.[*]

But you're totally right; small efficiencies aren't really the big 
issue. Though I did pick up a tip from someone else (think it may have 
been Jeremy) that s.equals("") is actually slower than s.length() == 0. 
I did some timings and it works out between 2 times (with no JIT) and 
10 times faster to do the zero length comparison. Thanks Jeremy!


[*] Actually, the Java one is 'Hello World Wide Web' :-)

View raw message