[
https://issues.apache.org/jira/browse/FREEMARKER-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16190249#comment-16190249
]
Daniel Dekany commented on FREEMARKER-80:
-----------------------------------------
OK, I got rid of that synchronized call. Please try if it's better with this
version:
https://dist.apache.org/repos/dist/dev/incubator/freemarker/engine/2.3.27-incubating-SNAPSHOT/
While it's surely bad that {{java.beans.PropertyDescriptor.getReadMethod()}} is
synchronized (and so I have worked that around), it does very little work
there, so with only 32 cores it's a little strange that it's an important
bottle neck. Well, it does {{Reference.get()}} inside it, so who knows... but
I'm a bit worried that it alone won't fix the performance issue. Anyway, I'm
also interested what the next bottleneck is.
> Performance bottleneck (from profiling)
> ---------------------------------------
>
> Key: FREEMARKER-80
> URL: https://issues.apache.org/jira/browse/FREEMARKER-80
> Project: Apache Freemarker
> Issue Type: Bug
> Components: engine
> Affects Versions: 2.3.26-incubating
> Environment: Linux, Java 8
> Reporter: Shevek
>
> Major performance bottleneck running on a 32-core system, limits effective
> number of threads to about 6: PropertyDescriptor.getReadMethod() is
> synchronized, and blocks other threads. Partial stack follows:
> java.beans.PropertyDescriptor.getReadMethod()
> BeanModel.invokeThroughDescriptor()
> BeanModel.get()
> Dot._eval()
> I suspect there's a workaround with using a method call directly in the FTL
> template, but I haven't figured it out yet. However, this is killing our
> performance. With Velocity, at the cost of a slower renderer, we can run all
> 32 cores, and get the job done faster.
> I'm not entirely sure how to figure out which piece of FTL is causing this
> stack.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
