https://bz.apache.org/bugzilla/show_bug.cgi?id=68089
John Engebretson <jeng...@amazon.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |---
--- Comment #6 from John Engebretson <jeng...@amazon.com> ---
Production data confirms the behavior change but shows minimal actual
performance improvement - it appears the extra work of hashing the string and
doing the HashMap lookup is comparable to the wasted effort of 12 string
comparisons.
I refined the approach by checking whether the attribute name was shorter than
the shortest special (length 30) and that eliminates the search cost for the
vast majority of calls. The attached speed test compares the cost of searching
for attributes with long vs. short names, and the current implementation of
getAttribute() is indeed slightly faster for short names (520ms vs. 540ms on my
PC).
With the length check, the short names are orders of magnitudes faster.
Presumably the JIT optimized it close to a no-op.
Checking for length 30 is an easy modification, but not the most maintainable.
Perhaps modify the static initializer to calculate the length of the shortest
special?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
