On 15/09/2015 20:37, Christopher Schultz wrote: > On 9/15/15 3:09 PM, Mark Thomas wrote:
<snip/> >> 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. > > Agreed. Doing work where no work is required is called waste :) If the > alternative was some overly-complicated mess of code, it would be worth > it to take the small performance hit in favor of maintainability. In > this case, the code is entirely straightforward. > >>> 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 ... ? > > Nothing. HttpMessages is gone from trunk. :) > Checking 8.0 HEAD shows the problem has been resolved, but I still agree > that there was only a theoretical and not an actual problem here in the > first place. I like the new implementation because it's faster and, > honestly, a bit more straightforward. I prefer the cleaner code too. At the moment I think there was an issue but I'm watching the discussion between those that have a better understanding of this issue than I do with a great deal of interest. I'm certainly learning a lot just from reading along. > In general, I'm not a big fan of lazy initialization unless there is a > significant advantage to delaying the work or there is a very good > likelihood that the work will never actually need to be done. +1 What makes some of the Tomcat code interesting is optimisations that made sense back in the days of Tomcat 4 (Java 1.3) may not apply today. > When the work produces a hug object graph, I like to use WeakReferences > so that the graph can be discarded under memory pressure and re-created > multiple times during a long-running process. Makes sense. I can't think of anything like that off-hand in Tomcat but +1 to the idea. Hmm. Some of the HTTP/2 priority stuff looks a bit like that. Something to keep in mind... Thanks. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
