2009/11/3 Mark Thomas <ma...@apache.org>: > Filip Hanik - Dev Lists wrote: >> On 11/02/2009 02:30 PM, Remy Maucherat wrote: >>> On Mon, 2009-11-02 at 18:46 +0000, ma...@apache.org wrote: >>> >>>> Author: markt >>>> Date: Mon Nov 2 18:46:21 2009 >>>> New Revision: 832039 >>>> >>>> URL: http://svn.apache.org/viewvc?rev=832039&view=rev >>>> Log: >>>> StringBuffer -> StringBuilder for o.a.naming >>>> >>> So I did not test or anything, but is SBuilder faster than SBuffer ? Or >>> it uses less resources ? >>> >> >> in most uses cases you'd barely see a difference. As speed locking has >> gotten much better. (my unqualified guess is that locking is optimistic) >> The only time you'd see a difference is if there was an actual >> contention on the resource, which with StringBuffers is rare too. > > I'm leaning towards not porting this to 6.0.x since there is no clear > performance issue caused by StringBuffer in 6.0.x. That said, the Javadoc for > StringBuilder is enough to convince me that we should make the change in trunk > as part of the general clean-up/improvement of the code for Tomcat 7. > > Mark >
In my opinion, this change in no way different from any other. Though it is not urgent, as nobody depends on it. If anyone can find some time to review and vote for any subset of those 50+ patches, and there will be enough votes, I will be happy to commit it. One benefit would be better alignment of TC 7 and TC 6 code and thus easier backport of patches. The 6.0 -> 5.5 backports will need the StringBuilder -> StringBuffer conversion anyway, so those are unaffected. Regarding the StringBuilder: They have a common base class, AbstractStringBuilder, that provides the implementation for them. What they add on top of it are classcasts, and synchronization. Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
