After a blog on Performance Improvements for Design Studio 1.5 here is one more blog with Design Studio Performance best practices in general. Although these topics may have been presented in earlier blogs, here you’ll find them revised and updated to the current Design Studio release.
Minimize the Number of Data Sources Loaded at Application Startup
By default, all data sources are loaded in Design Studio at application startup. For Design Studio applications with few data sources the application starts in sufficiently short time in the browser. However, the more data sources a Design Studio application has, the longer it may take until the application appears in the browser, as the application has to wait until all data sources have been loaded. This waiting time may be perceived by users negatively. One possible remedy is to reduce the number of data sources that are loaded at application startup.
To disable the loading of a data source at application startup, set the data source property “Load in Script” to “true”.
Later, when the data of the data source is actually needed (for example, when the user clicks a button), load the data of the data source in a Design Studio script with the Design Studio script method loadDataSource, for example:
DS_1.loadDataSource();
Incidentally, calling loadDataSource several times on a data source has no performance penalty, as all calls of loadDataSource following the first call are ignored.
Load Data Sources Only When Components Get Visible
Larger Design Studio applications may have components that are not visible right at application startup -- think of TabStrips with several tabs, Pagebooks with several pages, or any component that is initially invisible and shown, for example, upon a button click. You can improve the startup performance of your application by only loading the data sources of the visible components and not loading the data sources of the invisible components yet.
For example, you have a Pagebook of several pages with each page displaying the data of a different data source. One way to implement this efficiently is to load a data source only when the specific page of the Pagebook is selected. Add the following Design Studio script to the “On Select” event of the Pagebook:
if ((PAGEBOOK_1.getSelectedPageIndex() == 0)) {
DS_1.loadDataSource();
// ...
} else if ((PAGEBOOK_1.getSelectedPageIndex() == 1)) {
DS_2.loadDataSource();
// ...
} else if ((PAGEBOOK_1.getSelectedPageIndex() == 2)) {
DS_3.loadDataSource();
// ...
}
Recall from the previous section that you need to set the property “Load in Script” to “true” for all the involved data sources.
Note that calling loadDataSource several times on an already loaded data source is ignored and has no performance impact.
Incidentally, an even better version would exploit the fact that the page of the Pagebook which is visible at application startup (in this example this is the page with index 0 - but this is can be changed): Load the first data source DS_1 already at application startup (with its property "Load in Script" set to false) and use the following Design Studio script in the “On Select” event of the Pagebook:
if ((PAGEBOOK_1.getSelectedPageIndex() == 1)) {
DS_2.loadDataSource();
// ...
} else if ((PAGEBOOK_1.getSelectedPageIndex() == 2)) {
DS_3.loadDataSource();
// ...
}
When to Load Data Sources with Background Processing
The sections above implicitly suggest to avoid loading data sources at application startup when their components are not visible. If such an application design with few initially visible components is not possible, the following shows you how to improve the perceived performance of loading these data sources.
The idea is that the most important data sources are loaded first, while the less important data sources are loaded afterwards. While users focus their attention on components with data sources that are loaded initially, the Design Studio application loads the remaining data sources, which is not perceived as waiting time by the user. Loading the remaining data sources separately is done using a concept called “background processing”. Background processing consists of executing a Design Studio script in the “On Background Processing” event handler, which is executed asynchronously.
The basic steps are as follows:
- Configure the most important data sources such that they are loaded immediately by setting their “Load in Script” property to “false”.
- Trigger the background processing in the “On Startup” event handler with APPLICATION.doBackgroundProcessing().
- In the “On Background Processing” event handler load the remaining data sources with loadDataSource().
- (Optional) If loading the remaining data sources still takes a very long time (longer than the user would look at the components with the most important data source) and some of them are more important than the others you can load the remaining data sources in an iterative fashion.
For example, you have a Design Studio application with four data sources, the first two of them should be shown immediately. Then proceed as follows:
- Set the property “Load in Script” to “false” for data source DS_1 and DS_2.
- Set the property “Load in Script” to “true” for data source DS_3 and DS_4.
- In the “On Startup” event handler call APPLICATION.doBackgorundProcessing() (this is often the last line after all the other initialization script code).
- In the “On Background Processing” event handler load the data sources DS_3 and DS_4 with
DS_3.loadDataSource();
DS_4.loadDataSource();
If loading both DS_3 and DS_4 during the initial background processing take too long, you can split up their loading as described in step 4. While most of the steps above remain the same, the only step that you need to change is the last one:
- Create a global script variable, for example backgroundAction of type String, which is used to indicate which data source needs to be loaded.
- In the “On Startup” event initialize the value of backgroundAction before triggering background processing:
backgroundAction = "LOAD_DS_3";
APPLICATION.doBackgroundProcessing(); - In the “On background Processing” event add the following Design Studio script:
if (backgroundAction == "LOAD_DS_3") {
DS_3.loadDataSource();
backgroundAction = "LOAD_DS_4";
APPLICATION.doBackgroundProcessing();
}
if (backgroundAction == "LOAD_DS_4") {
DS_4.loadDataSource();
backgroundAction = ""; // not necessary, but good programming style
}
It is easy to see that you can extend this example with more iterations.
Incidentally, you can apply this concept not only in the “On Startup” event handler, but also in any other event handler, for example to trigger loading data sources when changing tabs in a Tabstrip component.
Note that background processing comes at a cost (for more details, see section "Background Processing Is Not For Free" in on Performance Improvements for Design Studio 1.5), so it’s best to use background processing only when needed.
Use a Single Data Source for Multiple Charts
When you have several charts, try to use a single data source with those charts and select the relevant data for the specific chart with the Chart property “Data Selection”:
This may involve redesigning the single data source as a superset of all the previously used data sources.
For example, you have one chart displaying data of a specific country, say Italy, and one chart displaying data of another specific country, say Spain. Then, instead of choosing two data sources – one for Italy and one for Spain – use a single data source containing country-specific data, including country-specific data for Italy and Spain. For the first chart use the Chart property “Data Selection” to select the data specific to Italy, for the second chart use the Chart property “Data Selection” to select the data specific to Spain.
Reducing the number of data sources in this way improves the performance significantly.
Selecting Data of Data Sources
There are several ways to select (or filter) data from a data source. They are discussed in the following list sorted by increasing performance:
setVariable
Lowest performance, involves round trips to multiple data sources
Using variables involves the concept of a variable container. A variable container permits sharing of variables among multiple data sources. Therefore setting even a single variable with setVariable may affect multiple data sources, resulting in a larger performance penalty.
See Design Studio: Performance Implications of Variables for more details.
setFilter
Medium performance, involves round trips to a single data source
Contrary to setVariable, calling the function setFilter always affects a single data source only. Thus, if possible, prefer setFilter over setVariable. This may require restructuring the data source, for example by using the Query Designer for BW queries or HANA Studio for analytical views or calculation views.
setDataSelection
Highest performance, involves no round trip
While setVariable and setFilter operate on data sources, setDataSelection operates on components, selecting a subset of the data in the data source assigned to the component (at the time of writing only Chart and data-bound SDK components support setDataSelection). This involves no round trip to the data source and is therefore the fastest of the listed options. A common pattern is to configure the data source to contain a superset of the data of interest and then to select the actual data of interest to the component with setDataSelection.
Conclusion
This is a living document and will be updated with new information. Be sure to come back or subscribe to this page if you are interested and want to stay up to date on Design Studio performance topics. Also have a look at SAP note 1931691 covering Design Studio performance topics.
You might be also interested in the following blogs:
Design Studio 1.5 - The Performance Release
Design Studio: Performance Implications of Variables