How quickly "should" an app start?

[chlebowa]

An app built with the following data and modules (no filters) takes over a minute to start*, up to a minute and a half with module_specific = TRUE. The data is not particularly large but larger than the typical example data used in NEST packages. Pre-processing takes about 10 seconds. Since modules do not start until viewed, the (near) entirety of app startup taken up by teal itself. I suppose building the filter panel is one of the more time-consuming steps.

*) Measuring in a fresh session, from runnig the script that attaches all necessary packages, creates data and modules, and runs the app, until the moment the notification Data loaded - App fully started up appears on screen.

My question is: at what point should one consider the app taking too long to start? Is there a way to improve startup time?

10 datasets of ~30 MB in total and 13 modules

``` > data ✅︎ verified teal_data object [L] Parent: Bindings: • ADRS: [L] • ADEX: [L] • ADLB: [L] • ADAE: [L] • ADVS: [L] • ADSL: [L] • ADDV: [L] • ADCM: [L] • ADTTE: [L] • ADMH: [L] ```

> sapply(ls(get_env(data)), \(x) dim(get_var(data, x))) 
     ADAE ADCM ADDV ADEX ADLB  ADMH ADRS ADSL ADTTE ADVS
[1,] 1934 9216   11  773 8400 24399 1200  400  1600 8982
[2,]   69   95   62   74  103    75   49   39    50   75

> modules
+ root
 + Summary Tables
  + Data Table
  + Cross Table
 + Data Quality
  + Variable Browser
  + Missing Data
  + Outliers
 + Exploratory Plots
  + Count Barchart
  + Distribution Plot
  + Bivariate Plot
  + Scatter Plot
  + Scatterplot Matrix
 + Statistical Analyses
  + Regression
  + Response Plot
  + Principal Component Analysis

Tagging @gogonzo for visibility.

Code of Conduct

• I agree to follow this project's Code of Conduct.

Contribution Guidelines

• I agree to follow this project's Contribution Guidelines.

Security Policy

• I agree to follow this project's Security Policy.

[chlebowa]

As evidenced by #1236, the creating the filter panel (FilteredData objects) is not the main culprit. Placing progress bars within filter panel ui or server functions did not yield additional information.

[gogonzo]

Tip to the assignee:
Moment when the FilteredData is created for the module should be postponed in the same way as the data-filtering. Creation of FIlteredData should be conditional on:

• if the data has changed
• if the tab is active

[gogonzo]

This can be closed. We have implemented following:

• for each module we create a single filteredData object instead of one for every module
• we postpone calling filter panel, transform module and module to the moment when tab is clicked

[chlebowa]

Thank you.

• for each module we create a single filteredData object instead of one for every module

You mean a singleton instead of one instance per module?

[gogonzo]

You mean a singleton instead of one instance per module?

@chlebowa Yup