You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by "Jarkko Viinamäki (JIRA)" <de...@velocity.apache.org> on 2008/07/25 12:59:31 UTC
[jira] Issue Comment Edited: (VELOCITY-606) Velocity 1.5
performance bottlenecks
[ https://issues.apache.org/jira/browse/VELOCITY-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616808#action_12616808 ]
wyla edited comment on VELOCITY-606 at 7/25/08 3:58 AM:
--------------------------------------------------------------------
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. InspectorBase.getMethod still seems to be a major bottleneck after applying patches 606 and 595.
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.
was (Author: wyla):
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: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org