[
https://issues.apache.org/jira/browse/VELOCITY-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615731#action_12615731
]
Nathan Bubna commented on VELOCITY-606:
---------------------------------------
Jarkko, can you tell where most time in ClassMap.findMethod/MethodCache.get is
spent? Is waiting for locks to be released or is it in MethodMap.find?
I'm hesitant to use any pre-1.5 ConcurrentHashMap implementation, as i have
read things about problems with backported versions. I've been given the
impression that it can't really be done right with the older JMM. Commons-lang
StrBuilder is fine.
I do, however, wonder how much longer we'll be supporting 1.4, as even Sun will
have finished "End-of-life"-ing it in October. I think once Velocity 1.6 is
released, we should move to JDK 1.5. This will open the door to many, many
improvements.
Anyway, back to the question at hand, i looked over ClassMap and do see a few
places little things can be improved. For instance, not all that happens
within MethodCache.get/put needs to be synchronized, like the call to
makeMethodKey(). Also, though it's not in the find() method, the
populateMethodCache() method seems quite overwrought and inefficient. I don't
see why it we call getMethods() and then checking each Method to see if it's
public. We should either drop the check or use getDeclaredMethods(). I prefer
the latter, as checking the modifiers of a lot of non-public methods is likely
to be faster than repeatedly doing MethodCache.put for inherited public methods.
Of course, i don't having any profiling set up on my machine right now, as the
stuff i work on for my company these days isn't the bottleneck for our apps.
I'll attach a patch with my suggestions, but i won't commit it unless someone
can confirm the performance improvements for me. (on that note, i'm also
hoping someone can test my patch for VELOCITY-595 as well :).
> Velocity 1.5 performance bottlenecks
> ------------------------------------
>
> Key: VELOCITY-606
> URL: https://issues.apache.org/jira/browse/VELOCITY-606
> Project: Velocity
> Issue Type: Bug
> Components: Engine
> Affects Versions: 1.5
> Environment: Win XP, 1 Gb, single core, Maven 2, JUnitPerf, JRat,
> cached Velocity templates with a ClassLoader
> Reporter: Jarkko Viinamäki
> Attachments: velocity-1.5-250-threads-loadtest.PNG,
> velocity-1.5-50-threads-loadtest.PNG
>
>
> I did some quite extensive profiling to identify performance bottlenecks in
> Velocity 1.5.
> Using Maven 2, JUnitPerf and JRat I was able to identify these methods as top
> bottlenecks:
> org.apache.velocity.util.introspection ClassMap -
> findMethod(String,Object[])
> org.apache.velocity.util.introspection IntrospectorBase -
> getMethod(Class,String,Object[])
> org.apache.velocity.runtime.parser.node SimpleNode - literal()
> org.apache.velocity.runtime.parser.node SimpleNode -
> render(InternalContextAdapter,Writer)
> org.apache.commons.collections ExtendedProperties -
> getBoolean(String,boolean)
> org.apache.velocity.runtime.parser.node ASTReference -
> render(InternalContextAdapter,Writer)
> The first two eat over 50% of the CPU with many threads. See attached
> screenshots.
> Interestingly enough the synchronized
> org.apache.velocity.runtime RuntimeInstance getTemplate(String,String)
> isn't a big problem when templates are cached. However, if all resources are
> not cached it becomes a serious performance bottleneck. ResourceCacheImpl
> also uses a synchronized map which slows things down.
> I think these bottlenecks could be at least made less worse by reducing
> synchronization by using ConcurrentHashMap and StringBuilder that ship with
> JDK 1.5. I'm investigating what kind of benefits could be achieved with those.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
