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? The way to remove race conditions from this code is to cache the values upon construction of the HttpMessages object, of course. I haven't yet read that blog post but I suspect it says that when possible, prefer doing one-time operations in constructors instead of using lazy initialization. In the case of this class, it seems that lazy initialization doesn't really buy us anything: those strings will be loaded eventually anyway. -chris
signature.asc
Description: OpenPGP digital signature
