Kuali Rice Development
  1. Kuali Rice Development
  2. KULRICE-8929

KRAD rederning is slow due to Freemarker's FMParser initializing LookaheadSuccess multiple times

    Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Won't Fix
    • Affects Version/s: 2.2
    • Fix Version/s: 2.3.0-m3, 2.3
    • Component/s: Performance
    • Security Level: Public (Public: Anyone can view)
    • Labels:
      None
    • 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 1.0.1.1
      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
    • KRAD Feature Area:
      UIF MVC
    • Application Requirement:
      KS
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required

      Description

      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.

        Issue Links

          Activity

          Hide
          Jerry Neal (Inactive) added a comment -

          Hey Dan,

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

          thanks,
          Jerry

          Show
          Jerry Neal (Inactive) added a comment - Hey Dan, How did you make this change locally? Did you build a patched Freemarker jar? thanks, Jerry
          Hide
          Jessica Coltrin (Inactive) added a comment -

          Jerry plans to have someone look at this for m3.

          Show
          Jessica Coltrin (Inactive) added a comment - Jerry plans to have someone look at this for m3.
          Hide
          Jerry Neal (Inactive) added a comment -

          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?

          thanks,
          Jerry

          Show
          Jerry Neal (Inactive) added a comment - 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? thanks, Jerry
          Hide
          Jerry Neal (Inactive) added a comment -

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

          Show
          Jerry Neal (Inactive) added a comment - Please retest after m3 change to remove interpret calls is in place
          Hide
          Larry Symms added a comment -

          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.

          Show
          Larry Symms added a comment - 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.
          Hide
          Jerry Neal (Inactive) added a comment -

          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.

          thanks,
          Jerry

          Show
          Jerry Neal (Inactive) added a comment - 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. thanks, Jerry
          Hide
          Daniel Epstein (Inactive) added a comment -

          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.

          Show
          Daniel Epstein (Inactive) added a comment - 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.
          Hide
          Jerry Neal (Inactive) added a comment -

          Hi Dan,

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

          thanks,
          Jerry

          Show
          Jerry Neal (Inactive) added a comment - Hi Dan, Could you attach the source available from Freemarker? It should be the same for these classes. thanks, Jerry

            People

            • Assignee:
              Jerry Neal (Inactive)
              Reporter:
              Daniel Epstein (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Structure Helper Panel