[
https://issues.apache.org/jira/browse/VELOCITY-607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621585#action_12621585
]
Christopher Schultz commented on VELOCITY-607:
----------------------------------------------
Thanks for re3moving that dependency -- I had forgotten that we had a JDK 1.4
requirement for compiling. I thought we were up to 1.5 these days.
You are swallowing an exception in your MapFactory class and allowing the
pre-JDK 1.5 code to kick-in instead. Your in-text comment says "this should
never happen". If that's the case, then you should throw some type of error. If
someone finds that this error is being thrown, they'll know to come to us and
we'll fix it. Otherwise, we may not be getting the speed improvement provided
by ConcurrentMap.
Good call on the difference between Hashtable and a synchronized HashMap: I had
forgotten that they had slightly different semantics.
If you choose to implement my "throw an error" strategy above, I woulod
recommend taking out the addition null check for your "map" reference afterward
-- because it should always be null.
> Runtime macro rendering very slow in Velocity 1.6-dev (679708) compared to 1.5
> ------------------------------------------------------------------------------
>
> Key: VELOCITY-607
> URL: https://issues.apache.org/jira/browse/VELOCITY-607
> Project: Velocity
> Issue Type: Bug
> Components: Engine
> Environment: Maven 2, JUnit, JUnitPerf, JRat, custom testbench:
> http://www.iki.fi/wyla/velocity/testbench
> Reporter: Jarkko Viinamäki
> Priority: Critical
> Fix For: 1.6
>
> Attachments: velocity-1.5-velocity24-test.PNG,
> velocity-1.6-dev-macro-performance-IDEAS-v2.6.patch,
> velocity-1.6-dev-macro-performance-IDEAS-v2.7.patch,
> velocity-1.6-head-20080725-velocity24-test.PNG
>
>
> The following test template (see VELOCITY-24):
> ## local macro, not global
> #macro(letter $char)
> This is the letter $char
> #end
> #letter("A")
> #letter("B")
> #letter("C")
> #letter("D")
> #letter("E")
> #letter("F")
> #letter("G")
> #letter("H")
> #letter("I")
> #letter("J")
> #letter("K")
> #letter("L")
> #letter("M")
> #letter("N")
> #letter("O")
> #letter("P")
> #letter("Q")
> #letter("R")
> #letter("S")
> #letter("T")
> #letter("U")
> #letter("V")
> #letter("W")
> #letter("X")
> #letter("Y")
> #letter("Z")
> ---
> Works quickly and correctly with Velocity 1.5 with several concurrent
> threads. However, 1.6-dev is a LOT slower (even 20x).
> The major performance bottlenecks seem to be:
> RuntimeMacro.render (60% of time)
> VelocimacroFactory.getVelocimacro (20% of time)
> With several threads this test also causes Velocity to throw error(s):
> org.apache.velocity.exception.MacroOverflowException: Exceed maximum 20 macro
> calls. Call Stack:letter->letter->letter->letter->letter
> at
> org.apache.velocity.runtime.VelocimacroFactory.startMacroRendering(VelocimacroFactory.java:179)
> at
> org.apache.velocity.runtime.RuntimeInstance.startMacroRendering(RuntimeInstance.java:1693)
> at
> org.apache.velocity.runtime.directive.VelocimacroProxy.render(VelocimacroProxy.java:200)
> at
> org.apache.velocity.runtime.directive.RuntimeMacro.render(RuntimeMacro.java:230)
> at
> org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:178)
> at
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:323)
> at org.apache.velocity.Template.merge(Template.java:324)
> at org.apache.velocity.Template.merge(Template.java:232)
> at
> org.apache.velocity.test.load.Velocity24Test.testRendering(Velocity24Test.java:51)
> This is related to VELOCITY-297 but the fix doesn't seem work with the new
> modified macro implementation.
--
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]
