[ 
https://issues.apache.org/jira/browse/VELOCITY-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarkko Viinamäki updated VELOCITY-606:
--------------------------------------

    Attachment: velocity-1.6-dev-concurrentmods.patch

Lots of small modifications to improve performance. Thread-safety and locking 
issues may exist and have not been fully verified.

> 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-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]

Reply via email to