How to Deal with Analytics Data Table's UI Responsiveness
This section summarizes some of the performance issues of Analytics Data Tables and their possible resolutions.
Note that this article refers to the number of displayed rows in the Data Table, typically from a few hundreds to a few thousands.
General Notes
- For Data Tables, there is a hardcoded limit of maximum 10 000 displayed rows (and maximum of 8 grouping levels). The number of rows in the underlying Datamart is not so relevant. But of course if there are millions of rows, at some point the backend query may also have an impact.
- Unless the user has a high end hardware (quad core CPU and 8+ GB of RAM), the UI will become very slow above 4 group by levels with 2000+ rows.
Issues
Data Tables Are Slow to Load
Issue: Data Tables may become really slow to load, and this is due to SmartGWT's processing of the grouping levels (well noticeable from 5 to 8 levels). (SmartGWT is a 3rd party underlying UI framework.) It is quite common to experience loading 4000+ rows for about one minute on a fast machine (i7 quad with 16GB of RAM) in any browser.Â
Resolution: See Conclusions below.Â
Unresponsive Application in Firefox
Issue: Once a Data Table has been displayed, the application may become very unresponsive in Firefox – for about as long as it took for the table to load.
Resolution: It is recommend to open the task manager, check out Firefox's CPU usage and leave the browser alone until it goes down. The experience shows that when trying to interact with the browser, it will take much longer to recover. Waiting is well worth it as Firefox then performs quite well once it has fully recovered.
UI Generally Less Responsive, Even After Switching Tabs
Issue: Once a Data Table has been displayed, the UI may become less responsive – even after switching to a different PFX tab. This behavior was observed on Mac with Chrome and Safari; presumably Chrome on Windows will perform similarly. It happens when 1000+ rows are displayed, either when the table is totally ungrouped, or when it is grouped with most or all of its nodes expanded.
Resolution: See Conclusions below.Â
Conclusions
To deal with the issues above, try the following:
- Make sure to filter the data if more group by levels are required.
- Check out the rollups functionality and use it where appropriate. Unless the tree view (the Group button below the grid) is required, rollups will solve these limitations.
- Save the Data Table in a grouped state. This is strongly recommended if the grouping functionality is indeed required and the performance impact becomes noticeable. The table will take longer to load but will have less of an impact if the tab remains open.
Found an issue in documentation? Write to us.
Â