You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@freemarker.apache.org by "Daniel Dekany (JIRA)" <ji...@apache.org> on 2017/10/03 11:11:02 UTC
[jira] [Commented] (FREEMARKER-80) Performance bottleneck (from
profiling)
[ https://issues.apache.org/jira/browse/FREEMARKER-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16189548#comment-16189548 ]
Daniel Dekany commented on FREEMARKER-80:
-----------------------------------------
Ugh... Seems that it's really time to put an indirection between {{java.beans.Introspector}} (and its products) and us. We have quite a few issues with it already. That's a non-trivial change though.
As of what causes it in the template, you just have a `someObject.someProperty` in the FTL.
You can call the getter method directly like {{someObject.getSomeProperty()}}, but that's awkward of course.
> 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)