tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <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
Date Tue, 15 Sep 2015 18:51:44 GMT
Chuck,

On 9/15/15 2:21 PM, Caldarale, Charles R wrote:
>> From: Christopher Schultz [mailto:chris@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


Mime
View raw message