[jira] [Commented] (FREEMARKER-80) Performance bottleneck (from profiling)

["Shevek (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/FREEMARKER-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16259713#comment-16259713 ] 

Shevek commented on FREEMARKER-80:
----------------------------------

Followup: We blew up some hard drives, so we're switching to live generation of pages. This means that we won't be hitting freemarker on 32 cores any more until our live userbase scales. But functionally, this release seems good and fast, thank you for the changes.

Personal note: I remember hitting the same issue with Introspector in an application of my own, and when I saw this, you had my sympathies. Sometimes a JDK1.1 API should have stayed in JDK1.1. Thank you again.

> 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)