https://bz.apache.org/bugzilla/show_bug.cgi?id=69381
John Engebretson <jeng...@amazon.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
OS| |All
--- Comment #2 from John Engebretson <jeng...@amazon.com> ---
Adding details and speed test:
1. The speed test is attached, based on TestELParserPerformance
2. The test is most consistent when run with "-Xmx3g -XX:+UseParallelGC". I'm
finding this to be good when the test generates high object allocation.
Typical result from current state:
${beanA.name} duration=[348ms] or 348 ns each
${beanA.getName()} duration=[1421ms] or 1421 ns each
${beanB.getName()} duration=[2023ms] or 2023 ns each
Then change Util.findMethod() along these lines:
private static final Map<Class<?>, Method[]> methodsByClass = new
ConcurrentHashMap<>();
Method[] methods = methodsByClass.computeIfAbsent(clazz, (key) ->
clazz.getMethods());
// Method[] methods = clazz.getMethods();
and we get:
${beanA.name} duration=[351ms] or 351 ns each
${beanA.getName()} duration=[809ms] or 809 ns each
${beanB.getName()} duration=[862ms] or 862 ns each
What we see:
1. The non-reflective call is unaffected. Repeated runs show small variation
up or down.
2. The reflective call with five properties (beanA) is 44% faster
3. The reflective call with ten properties (beanB) is 55% faster
FWIW I found some complex generated beans involved with over 40 properties.
Fortunately those are rare, but it illustrates that the higher method counts
are a real problem.
--
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
