[KULRICE-8929] KRAD rederning is slow due to Freemarker's FMParser initializing LookaheadSuccess multiple times Created: 06/Feb/13  Updated: 08/Oct/13  Resolved: 16/Jun/13

Status: Closed
Project: Kuali Rice Development
Component/s: Performance
Affects Version/s: 2.2
Fix Version/s: 2.3.0-m3, 2.3
Security Level: Public (Public: Anyone can view)

Type: Improvement Priority: Critical
Reporter: Daniel Epstein (Inactive) Assignee: Jerry Neal (Inactive)
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File KSENROLL-5152_changed_FMParser_to_have_a_static_LookaheadSuccess_instance.patch    
Issue Links:
relates to KULRICE-6557 Improve Performance and Memory Consum... Closed
is related to KSENROLL-5152 KRAD renderning is slow due to Freema... Closed
Similar issues:
KULRICE-8928Improve initialization of FreeMarker Parser
KULRICE-11869FreeMarker error in testTransactionView
KULRICE-12988KC app startup time really slow with the latest rice 2.5 revision
KULRICE-12605KRAD property editors aren't loaded due to KNS spring configuration that overrides KRAD configuration
KULRICE-4037KFS user preference records cause batch slowness due to too many krew_usr_optn_t records in Rice
KULRICE-531development slowness
KULRICE-8442Module locking needs converted to FreeMarker
KULRICE-12991Application startup time slow after Spring 4.0.x upgrade
KULRICE-13780Create Freemarker 404 AFT
KULRICE-10353Inline processing of FreeMarker templates
Rice Module:
KRAD Feature Area:
Application Requirement:
KAI Review Status: Not Required
KTI Review Status: Not Required


I was doing some profiling on our application and a huge amount of time is being spent in the initialization of FMParser which is creating an exception called LookaheadSuccess. The way the exception is initialized many times, it will always fill in the stacktrace which is a very expensive operation and could be made much faster using a static variable. This has the potential to give KRAD a noticeable performance gain.
See: http://freemarker.624813.n4.nabble.com/Flow-control-by-Exception-td626112.html

After making the change locally, render time went from 7 seconds to 2.

Comment by Jerry Neal (Inactive) [ 07/May/13 ]

Hey Dan,

How did you make this change locally? Did you build a patched Freemarker jar?


Comment by Jessica Coltrin (Inactive) [ 11/Jun/13 ]

Jerry plans to have someone look at this for m3.

Comment by Jerry Neal (Inactive) [ 14/Jun/13 ]

Hi Dan,

This is difficult to add. It actually can't be modified in Freemarker itself because it comes from JavaCC. I saw a comment from someone who modified the build but I wasn't able to find that. In addition, I worry about the classpath approach because I think it could vary when both Freemarker and Rice are dependencies.

However, they also mentioned this is caused by use of interpret. We have removed all our use of interpret, so I don't think this will get hit anymore. Can we see what that change does in m3 and then see if this is still a problem?


Comment by Jerry Neal (Inactive) [ 16/Jun/13 ]

Please retest after m3 change to remove interpret calls is in place

Comment by Larry Symms [ 12/Aug/13 ]

could you add some comments as to why this was marked as won't fix? I see there's a related issue with a pile of subtasks but I don't see any that directly address this issue. Won't fix usually indicates a non-issue which is definitely not the case here.

Comment by Jerry Neal (Inactive) [ 12/Aug/13 ]

Hi Larry,

Sure thing. First we introduced a custom Freemarker directive that removes the need to do Freemarker interpret calls. These were really expensive, I think were also invoking this problematic code (although I am not entirely sure which is why I was hoping it could be re-tested, I left another note about this above).

Besides that, we don't have a way to make the change. The modification that was put into KS relies on classpath ordering. This works out ok if the overridden class file is in the project. But if the override is in another jar, there is no guarantee it will load in the correct order. Also, we do have a custom Freemarker project, but the code actually gets generated by the Javacc.

Had KS upgraded to m3? Just curious if the problem is still there.


Comment by Daniel Epstein (Inactive) [ 01/Oct/13 ]

Hey Jerry, restesting is difficult as the source code for the custom freemarker library (2.3.19-patch3) you are using is not available in the repository.

Comment by Jerry Neal (Inactive) [ 08/Oct/13 ]

Hi Dan,

Could you attach the source available from Freemarker? It should be the same for these classes.


Generated at Tue Mar 31 23:42:03 CDT 2020 using JIRA 6.1.5#6160-sha1:a61a0fc278117a0da0ec9b89167b8f29b6afdab2.