On 15/09/2015 19:51, Christopher Schultz wrote: > Chuck, > > On 9/15/15 2:21 PM, Caldarale, Charles R wrote: >>> From: Christopher Schultz [mailto:ch...@christopherschultz.net] >>> Subject: Re: svn commit: r1702821 - in /tomcat/tc8.0.x/trunk: >>> java/org/apache/tomcat/util/http/HttpMessages.java >>> webapps/docs/changelog.xml >> >>> What's the reason for caching references to the return value of >>> sm.getString()? Is there a significant performance advantage? >> >> There's a whole lot of stuff going on inside that method, including >> string formatting based on locale. Definitely not something you want >> to keep redoing for frequently used statuses. > > No string formatting, and the Locale should have already resolved by the > time the first call was made to StringManager.getString. > > For a PropertyResourceBundle, this amounts to the same amount of work as > HashMap.get(). (Though it might actually be Hashtable.get, which is a > bit slower). > > So yes, it's nice to cache this value but I'm interested to see > performance numbers. Did anyone do a benchmark already?
Yes, I did a micro benchmark on that code. I even committed it so you could have run the test yourself in less time that it took to wrote tis e-mail. The cached String values are returned approximately 2 orders of magnitude faster. OK we are talking about 10s of nano-seconds vs. fractions of nanoseconds so it is almost certainly in the noise but I couldn't see a good reason to drop the cache and make things fractionally slower for every request. > > The way to remove race conditions from this code is to cache the values > upon construction of the HttpMessages object, of course. And if you look at the latest version of that class you see ... ? Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
