Performance testing and optimization is an important part of the development process. This includes testing the application in an environment as close to production – resources, data, and usage – as possible. You can see dramatic variances in the same environment with small increases in concurrency.

Of course, all aspects of your application play a role in the performance. Architecture, resources, amount of data, data structure, data model, UI design, UI calculations, concurrency all build a performance matrix. Let’s focus here on some key aspects you can focus on as a UI developer.

Optimize Expressions

There are some common functions that can be heavy in UI load and response times. As a developer, efforts should be made to avoid the following calculations and utilize other techniques to achieve the needed results.

Avoid if() statements:

• Conditioning expressions slows down the processing speed. If() statements can usually be rewritten with pick() or match() functions. Utilizing control tables can help facilitate these techniques.
• One exception to this is the use of if() to limit chart results. Using dimension limits can solve a UI need to show a certain number of records, but there is no performance benefit to using them. The entire chart is still calculated, not just the reduced number of rows. An if() function in the chart expression can limit the number of rows actually calculated.

Aggr() functions can lead to some significant performance challenges. They cannot always be avoided, but an awareness of the performance cost will be helpful during design and development. You should be cautious about the how they are used and what other functions are nested with them.

Unnecessary TOTAL <> qualifiers can add calculation time. In an effort to reuse an expression across dynamic tables with many dimension options, it may be tempting to include extra dimension qualifiers in your TOTAL expressions. It is much more efficient in terms of calculation times to use separate expressions and enable Conditional expressions where necessary.

Another expensive calculation is utilizing {1} state identifier in set analysis. Calculations accessing the full data set vs a reduced data set based on selections require more CPU and time to return results. There are definitely many cases where we need to use {1}, but we should always evaluate the expression and consider alternatives.

A fairly surprising find during performance optimization was the effect of using the num() function around expressions. It seems like an easy way to streamline and reuse expressions as well as format text objects such as KPI’s, but developers should be aware that there is a calculation cost to using this function. A more performance friendly technique is to use table objects for KPI’s and condition expressions for each number format, utilizing the number properties tab.

Rank() functions can be expensive, especially when used in combination with aggr(). Experiment with other techniques and compare response times to determine the best method within your application. In some cases, FirstSortedValue() or rank as a calculated dimension vs an expression may calculate quicker.

Performance testing is an important part of the implementation of each application. Keeping the above tips in mind during development can help yield good results and minimize rework.

Nicole Abernethy, Sr Consultant