You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by "Nathan Bubna (JIRA)" <de...@velocity.apache.org> on 2008/07/29 23:57:31 UTC
[jira] Resolved: (VELOCITY-606) Velocity 1.5 performance
bottlenecks
[ https://issues.apache.org/jira/browse/VELOCITY-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nathan Bubna resolved VELOCITY-606.
-----------------------------------
Resolution: Fixed
Fix Version/s: 1.6
Ok, all patches provided for this issue so far have been committed. So far as i can tell using Jarkko's testbench, the hotspots he identified at the top of this issue have all been cooled significantly. Rather than continue using this as a catch-all for performance bottlenecks, i'm marking this resolved and leaving remaining performance problems to their own JIRA issues (e.g. VELOCITY-607).
Jarkko, if you feel this issue is not resolved, please feel free to re-open!
> 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
> Fix For: 1.6
>
> 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