[
https://issues.apache.org/jira/browse/VELOCITY-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616808#action_12616808
]
Jarkko Viinamäki commented on VELOCITY-606:
-------------------------------------------
OK. I did some profiling with latest SVN head (679708). I have some good news
and bad news.
The good news is that the current head is slightly faster than 1.5 with some of
my test templates. ClassMap.findMethod still seems to be a major bottleneck.
However, the bad news is that modifications made to the macro system in 1.6
have made concurrent macro processing extremely slow and templates with many
invocations to the same macro sometimes fail with
"org.apache.velocity.exception.MacroOverflowException: Exceed maximum 20 macro
calls. " when there are many concurrent threads. I'll file a separate issue
about this.
My pathetic little testbench is available at:
http://www.iki.fi/wyla/velocity/testbench (free to use)
With that it's relatively easy to run load tests and use JRat as profiler.
> 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-1.6-dev-concurrentmods.patch,
> velocity-1.6-dev-concurrentpatch-250-threads-loadtest.PNG,
> velocity-1.6-head-20080725-test.vm.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]
