Brad Cox [mailto:[EMAIL PROTECTED]] wrote:
> At 11:03 AM -0800 01/25/2001, Mel Martinez wrote:
> >That presumes the line termination
> >character of choice for the output is a linefeed
> >character.
>
> Good point. Will fix when I get a moment.
>
> >Another issue is that the example creates catenated
> >String literals. I would hope that the actual code
> >produced would use appropriately initialized
> >StringBuffers or performance could be a problem.
>
> I've been assuming that concatenation of constants is collapsed
> at compile time. I'm sure this is true for SOME compilers but
> less sure this is true across the board. Could you elaborate
> on this point?
>
> Concatenation of non-constants is, of course, a different
> matter. I do use StringBuffers for these.
>
Dangerous to put too much faith in compilers, eh? :-)
In general, for any code that is catenating strings, als
msg = "some string" + param + "some other string";
it is usually faster to use a StringBuffer like so:
msg = new StringBuffer();
msg.append("some string").append(param).append("some other string");
However, that in itself does not necessarily improve performance. The
StringBuffer class defaults to a size of only 16 chars. Thus, as soon as
the catenation result exceeds 16 chars, it has to reallocate the internal
buffer. If you then exceed the new size (it will double in size or go to
just large enough to hold the new data, whichever is larger) on a subsequent
append, it will have to reallocate again, and again. Adding 10 chars at a
time to a StringBuffer will cause 3 reallocations by the time
you get to a hundred characters. Actual performance impact will depend on
your particular application and the nature of the data.
So basically operations that add lots of small chunks adding up to a much
larger whole, will force numerous reallocations up until you've catenated
just over half the data at which point it will finally bump up to enough
room for the entire result.
Given this tidbit of knowledge, you should try to anticipate how large the
final StringBuffer needs to be to hold the entire result. You don't have to
hit it exact, and if you make it too large, you may run up against memory
constraints (depends on your application and runtime).
My suggestion is to try to guess the halfway mark. That way, you won't be
wasting too much memory, but will significantly reduce the number of buffer
reallocations (which cost a call the System.arraycopy() each time!).
So in the above example, suppose I can anticipate that the non-constant
Strings are going to be on the order of ~25 chars and that the constant
strings add up to about 75 so that my final String will be around ~100
chars. If I initialize the StringBuffer to about 64 chars, I can be sure
that it won't resize more than once. If memory is not a problem, then I
might go for the fastest situation and just do something like
msg = new StringBuffer(128);
so that I can be fairly sure I won't be reallocating.
I hope that this is helpful. Actual mileage may vary.
I'll defer for now on the relative merits of JSP versus other schemes. I've
got too many other things to worry about.
Cheers,
Dr. Mel Martinez mailto:[EMAIL PROTECTED]
Software Architect phone:410-423-3931
G1440, Inc. http://www.g1440.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
