On 23/09/2014 17:59, Phil Steitz wrote: > On 9/21/14 7:29 PM, Phil Steitz wrote:
<snip/> >> I was not able to demonstrate any consistent performance difference >> in my tests. The code in trunk was a tiny bit faster on average but >> some runs of the patched code were faster than some runs of the >> unpatched code. It might be worth just changing the max to be "lock >> free" and seeing if that change by itself makes any difference. > > I did that and still could not demonstrate any improvement. The > report in the ticket does show monitor contention, though, so I am > ambivalent on this one. What do others think? Typo: s/Mast/Must/ I have often found that for large numbers of cheap operations that monitoring tools are far more overhead than the thing they are trying to measure. I recently spent some time tuning a new Cookie parser for Tomcat and the profiler results were useless at identifying the real bottlenecks. I wonder if that is happening here. I have no objection to the patch if the performance is about the same. Adding max to the StatsStore is likely to be useful elsewhere. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
