[
https://issues.apache.org/jira/browse/VELOCITY-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616051#action_12616051
]
Jarkko Viinamäki commented on VELOCITY-606:
-------------------------------------------
I made some modifications using java.util.concurrent and some small tricks to
optimize the code. In my tests (which uses macros and most of the velocity
directives) I was able to get over 20% performance boost.
Although all tests pass and I was able to run Velocity app on Jetty with quite
high load (70 concurrent users constantly bombarding with 0 delay) and I didn't
see any errors, there can certainly be concurrency problems, race conditions
and all that nasty stuff in my modifications. Feel free to laugh at my
incompetence. :)
Modified jar, patch and screenshots are here:
http://www.iki.fi/wyla/velocity/
I'll also include them as attachment.
---
Regarding ConcurrentHashMap: if I'm not mistaken, there was some fix in the
Java memory model in JDK 1.5 so there might be some problems with the
backported version. Also licensing issues regarding that are a bit unclear.
Further JDK 1.6 is faster than 1.5 and 1.5 is faster than 1.4 so I wouldn't use
an old version in production.
> 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]
