This document will describe the impact of the content of an application on the performance.
Basic Impact
I would not consider much the size of the application itself.
What counts is:
- number of data sources
- number of components and complexity of components (e.g. 5 crosstabs are more expensive then 5 buttons
- lines of scripts which need to be executed on user interaction
Data Sources
Basically, every application is different as the biggest difference is on the data source part. Pick up of the ResultSet is the more expensive, also getting of all members from dimension, getting of hierarchies are expensive.
Method: "DS.getDataAsString()"
The data will be got from result set. If you do not have any data bound component like crosstab or chart, this call causes that the result set is fetched from source system (BW, HANA) to the Java stack. This means complete result set is pulled. Then the selection will be done (and this should not have too much performance effect). Also, if you have 2 such calls on same data source, the second should not fetch the result set again (unless you change filters or variables in between).
- Technically the complete result set as you can see on the data source is loaded from the BW / HANA system into the Java stack. This means also, if you do not have a crosstab on the data source, you will see the impact of a small "getData" call in the first use - but the second will be very cheap.
As the number of data sources has the biggest impact, you should try to use as much as possible the "Data Selection" functionality in charts.
Method: "DS:getMemberList()"
This needs to ask the source system for the members independent of the result set - therefore this is not causing any fetch of result set. But when you request many members (1000+) the transfer is taking also place (there is some cache in Java stack, so the second call should not always call again the fetch).
Components
Components must be stored in memory, but the impact is not big - as all components have a unique ID the implementation is quite performant. As design studio is processing rendering in delta mode, the impact of panels for structuring the application is not high, you should not remove too much just because you want to reduce the number.
An addition, having a panel which will be shown or hidden by user interaction is less expensive then showing / hiding 10 single components which are located in the panel.
Of course, use of an component which sends to the client only content information and represents only one component in the application (like a "TILE" with values) is better than an "own build" visualization with many panels and sub-panels and texts or other content blocks.
Scripts
Technically, the scripts are executed on the server in Rhino Engine, but sometimes must be interrupted and processed outside of the Rhino engine. such interruptions are a bit more expensive, but still in the majority in milliseconds area. As you cannot impact the interruptions, you do not need to consider those.
Another point is variables handling in scripts. As many scripts functions are requiring submitted variables, you should avoid sequences where you submit some values and then resubmit with different values. But also this can be checked.
BIAPP File Limit for the application
Until now we have not faces any issues in respect to the file limit. The BIAPP file is an XML format, but it will be parsed before the execution. This is done actually only once after startup of the server and is cached user independent. Then as soon the object model is built up the file size does not matter. Of course there is some relation between the file size and number of data sources, components and scripts...
How To Analyze your Application?
For the analysis I can recommend the blog of my colleague, Martin Kolb: Design Studio Tips and Tricks: Measuring Performance.
Check up also the blog "Optimize the performance of your SAP BusinessObjects Design Studio solutions – tips and tricks" by Pierre COMBE.
Updates
13.11.2014: some wors on methods "DS.getDataAsString()" & "DS:getMemberList()"