Uploaded image for project: 'Kuali Rice Development'
  1. Kuali Rice Development
  2. KULRICE-6757

KSPD: Investigate Optimization options for ViewServiceImpl

    Details

    • Type: Task
    • Status: In Progress
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 2.2.0-m4
    • Fix Version/s: Backlog
    • Security Level: Public (Public: Anyone can view)
    • Labels:
    • Epic Link:
    • Rice Module:
      Rice Core, KRAD
    • Application Requirement:
      Rice
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required

      Description

      In recent performance tests focusing on KRAD elements ViewServiceImpl has shown to be a potential spot in our code that could use optimization. Attached is a sheet with time breakdown for the ViewServiceImpl.bulidView which is particularly of interest.

        Attachments

          Issue Links

            Activity

            Hide
            mztaylor Martin Taylor (Inactive) added a comment -

            Notes: switched to app dynamics lite for some testing. Showed several calls related to getViewById (2,3,5 sec); tracing back with yourkit it was between its UifDictionaryIndex and the Beans generated/populated. Did some searching for ways to improve speed with bean generation/population but didn't come up with any solutions yet.

            Show
            mztaylor Martin Taylor (Inactive) added a comment - Notes: switched to app dynamics lite for some testing. Showed several calls related to getViewById (2,3,5 sec); tracing back with yourkit it was between its UifDictionaryIndex and the Beans generated/populated. Did some searching for ways to improve speed with bean generation/population but didn't come up with any solutions yet.
            Hide
            jkneal Jerry Neal (Inactive) added a comment -

            Martin,

            For now just focus on the build view method. I have some ideas on the getview and template rendering. On the build view, if we could narrow down a method that is either getting call many times (and we could make some gains by gaining a few milliseconds for each call) that would give us something to start with.

            thanks,
            Jerry

            Show
            jkneal Jerry Neal (Inactive) added a comment - Martin, For now just focus on the build view method. I have some ideas on the getview and template rendering. On the build view, if we could narrow down a method that is either getting call many times (and we could make some gains by gaining a few milliseconds for each call) that would give us something to start with. thanks, Jerry
            Hide
            mztaylor Martin Taylor (Inactive) added a comment -
            • testing getCanonicalName in the CloneUtils::getFields to see if I can improve performance there
            Show
            mztaylor Martin Taylor (Inactive) added a comment - testing getCanonicalName in the CloneUtils::getFields to see if I can improve performance there
            Hide
            mztaylor Martin Taylor (Inactive) added a comment -

            Spending time trying to make use of the KRADTestCase and junit-performance in the testing of collectionGroupBuilder, Running into issues when building the Uif objects (running performInitialization at part of the before). Need to find out more about the cloneUtils and why they are used in place of a pre-existing solution (XStream, another java deep cloning util) and if one of those tools would work/would be faster (via kradtestcase/junit-pref)

            Show
            mztaylor Martin Taylor (Inactive) added a comment - Spending time trying to make use of the KRADTestCase and junit-performance in the testing of collectionGroupBuilder, Running into issues when building the Uif objects (running performInitialization at part of the before). Need to find out more about the cloneUtils and why they are used in place of a pre-existing solution (XStream, another java deep cloning util) and if one of those tools would work/would be faster (via kradtestcase/junit-pref)
            Hide
            jcoltrin Jessica Coltrin (Inactive) added a comment -

            moving non-blocker and non-critical m4 Jiras to 2.2-backlog

            Show
            jcoltrin Jessica Coltrin (Inactive) added a comment - moving non-blocker and non-critical m4 Jiras to 2.2-backlog

              People

              • Assignee:
                Unassigned
                Reporter:
                masargen Matt Sargent
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated: