[
https://issues.apache.org/jira/browse/VELOCITY-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617671#action_12617671
]
Nathan Bubna commented on VELOCITY-606:
---------------------------------------
Ok, so when i started helping with this, i assumed most synchronization was
present because it needed to be for some reason, and that i could largely help
by making it more fine-grained. I'm increasingly convinced that many of the
synchronization hotspots are totally unnecessary. Particularly, it seems
there's quite a few places where it is harmless to let multiple threads
initially pass by a "get" duplicate creation/search work and then override
earlier "put" calls. I've removed synchronization from some of them, all
tests pass and there are no errors when load testing with Jarkko's testbench.
I'll keep an eye out for more of these...
> 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]
