Logging Script Performance in Applications in Performance View Popup

You can log the performance of scripts used in your analytic or planning application by using a parameter in the application URL and a key combination to display a performance swim lane diagram that comes up as a popup inside your application.

  1. Enter the parameter APP_PERFORMANCE_LOGGING=true in the application URL
    Tip

    Enter the parameter APP_PERFORMANCE_LOGGING=true in front of the # character in the URL and precede the parameter with a question mark ?.

  2. Click Ctrl +Shift+A to display a popup with the performance results as a swim lane diagram.

In the swim lane each script event is represented as a line. The lines are numbered consecutively. As the scale is the same for all events, you can immediately identify long running events in the swim lane

If there are some performance relevant events during the script execution (which can be ideally optimized by you as an application designer) they are also visible below the triggering event as separate swim lane with the same scale. Tooltips display more detailed information about the particular event including the exact runtime duration.

To have a better overview you can hide some measurements by clicking on the script measurement blue bar. To refresh and show all measurements again, click Show all.

There are currently two different events that can be visualized as red bars in the swim lane diagram:
  • Waiting for [widget name] to be loaded in background means that a script tries to access a widget which is not loaded at the particular point in time. The scripts are in waiting position until the widget is loaded in the background. This can be only the case if background loading for widgets is used. To avoidlong loading times for a widget you can do one of the following:

    • use the widget at a later point in time

    • use the widget action Always initialize on startup

  • Fetch description for member [member id] from dimension [dimension id] means that fetching description from the backend system for the member id was necessary because only the member id was used for filtering using the setDimensionFIlter function. To avoid the fetching of the description, you can use a MemberInfo object (like {id:"some_id", description:"Some Description"}) for filtering instead of the simple member id string.