[
https://issues.apache.org/jira/browse/VELOCITY-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Bubna updated VELOCITY-606:
----------------------------------
Attachment: VELOCITY-606.patch
Ok, here's a more significant patch that should speed up MethodMap.findMethod
somewhat, uses less synchronization in general, and uses much finer-grained
locking for ClassMap$MethodCache.get. All tests still pass, but i still
haven't run any performance testing on this.
I'll try to find some time to set up a profiler and see if these things really
make a difference, but i would be much obliged if someone else had the time to
do so.
Oh, and this is all without using ConcurrentHashMap or StrBuilder, as i'd
prefer to first see what can be done w/o introducing new dependencies.
> 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, VELOCITY-606-light.patch,
> VELOCITY-606.patch
>
>
> 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]
