tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Caldarale, Charles R" <Chuck.Caldar...@unisys.com>
Subject RE: Access Log /Filter/?
Date Wed, 03 Mar 2010 18:37:10 GMT
> From: Xie Xiaodong [mailto:xxd82329@gmail.com]
> Subject: Re: Access Log /Filter/?
> 
> http://www.javalobby.org/java/forums/t88518.html

I think you're cherry-picking the data.  The most useful comment about StringBuilder in that
thread was this:

"Re: StringBuffer
> Thus, the performance of the two classes becomes identical.

Reality is more complicated than that.
- You can't rely on latest/hardest optimizations in the HotSpot Client VM, which is the VM
you gotta use for most desktop apps, games and others.
- Optimizations are not portable. Just because Sun has optimizations X it doesn't mean that
IBM, BEA, GCJ etc. (even at the same Java SE level) have it too, and vice-versa.
- Optimizations are fragile and difficult to predict. Say you have a StringBuffer that is
non-escaping (thus benefits from lock elision etc) because it's a local var of a single method.
Now if this method grows too big and you refactor it into multiple smaller, private helper
methods, suddenly the StringBuffer is passed from one method to another and it's not anymore
a non-escaping local... unless, thanks to inlining or smarter escape analysis, the optimized
code can handle it again as non-escaping... but now you're depending on a combination of several
optimizations, and it's increasingly difficult (at least for the average developer) to predict
the compiler's behavior and to rely on its behavior.

Conclusion (for this particular optimization): Using StringBuilder is no more complex than
StringBuffer, so there's no excuse to not use it when you now the buffer is unshared. Unlike
some other optimizations, this doesn't confuse your code, doesn't create maintenance problems
or incur increased development cost. in cases like this - where writing optimal code is just
as easy as non-optimal code - I'd optimize since version 0."

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus
for use only by the intended recipient. If you received this in error, please contact the
sender and delete the e-mail and its attachments from all computers.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message