[
https://issues.apache.org/jira/browse/VELOCITY-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616152#action_12616152
]
Nathan Bubna commented on VELOCITY-606:
---------------------------------------
That's quite a wide mix of changes. Unfortunately, we will not be adding a
dependency on JDK 1.5 for Velocity 1.6, so many of those can't be used. Yes,
the new versions are faster, but there are many other concerns and interests
out there besides performance. I'm certainly going to be in the crowd
lobbying for a JDK 1.5 requirement in any Velocity 1.7 version, but it just
isn't time to go there yet. And yeah, it sounds like you and i have heard
similar things about the dangers of ConcurrentHashMap implementations under the
older memory models. As for Commons-Lang's StrBuilder, we already depend on
some Commons-Lang classes, so i think we ought to upgrade our version and use
that class for now instead of StringBuffer or JDK 1.5's StringBuilder.
So, while i appreciate the work you've done, would you consider adapting it to
fit our JDK 1.4 requirement? :)
Also, it looks like my patch(es) contain a number of things that yours does
not. As i do not have any profiling tools or tests set up on my machine, i
can't confirm the improvements. If you are looking for gains that do not
require JDK 1.5, you might consider testing some of my changes as well. They
should offer some improvement without using ConcurrentHashMap.
Finally, i'm impressed by the way you went about de-synchronizing
ResourceManagerImpl. It looks like a reasonable fix for VELOCITY-595. I'll
definitely be giving that a try and posting it over on that issue too.
> 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]
