> From: Xie Xiaodong [mailto:xxd82...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
