[ https://issues.apache.org/jira/browse/VELOCITY-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615604#action_12615604 ]
Malcolm Edgar commented on VELOCITY-606: ---------------------------------------- Very interesting, always keen to see how we can improve Velocities performance. With regard to the alternative classes, I believe supporting JDK .14 is still very important in Velocity so I would be keen to use alternative 1.4 compatible implementations: EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap and org.apache.commons.lang.text.StrBuilder regards Malcolm Edgar > 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 > > > 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]