UPCOMING WEBINAR: Optimize product ranges using TURF, Factor, and Correspondence Analysis Since Displayr runs in a browser, it has built-in precautions so that outputs that are too large for the browser to render are dealt with so the browser doesn't crash, and very large tables may be truncated so they do not slow down the document. However, even if they're below those limits, tables can still sometimes take longer than ideal to calculate and display on a page. If a table is slow to calculate or seems to take an unreasonably long time to compute, sometimes the slow table is exactly what you need to run so there isn't much to improve, but in many cases, there are things you can do to address the root cause of the slowness.
Please note this requires the Data Stories module or a Displayr license.
Tables can take a long time to compute for a variety of reasons. Including:
- The table is using a large amount of data. For example, a Binary-Grid variable set with 20 rows and 20 columns will be computed using 400 variables. It will take time to both extract the data and compute the variables. The speed can also be compounded by the number of statistics shown on the table, the number and complexity of rules applied, and if the table has column comparison significance testing enabled. The arrows, font colors, or arrows and font colors tests don't run as many individual tests so they run faster than column comparisons. Even though very large tables are truncated at 3000 cells in the browser, the full table of data is available to R-based outputs and Calculations and when the table is exported to Excel.
- You are using banners when there is no need to use them. For example:
- If there is only one question in your banner, it will generally be much faster to select that question in the Columns dropdown of the table directly. The reason for this is that banners create additional variables for each category of the question used. For example, if you have a question with, say, 100 categories, it creates 100 variables, which can substantially slow down performance.
- If a banner consists of nested Nominal questions, such as gender-within-age, creating new variables for each category by filtering one variable set by the other will achieve substantially faster computational performance than using a banner.
- If a banner includes a variable that is only being used as a filter, it will generally be substantially faster to remove it from the banner, and instead, use it to Filter the table.
- The variables being used in the table are JavaScript Variables which are computed using lots of other variables. When such variables are used in analysis Displayr needs to first load all the input variables and then compute the variables prior to computing the table.
- An Experiment or Ranking variable set is used in the table. When a table uses Experiment or Ranking variable sets, advanced models run in the background to calculate the coefficients and probabilities shown on the table. This can be exacerbated by the number of variables grouped in the variable set and cases (responses) used to calculate the results.
- If calculated variables are very slow then consider using saving out a copy of your data file with the calculations "hard-coded". You can do this as a file you download or to the Displayr Cloud Drive. This may make a larger data file, but may also save time overall, particularly with large or complex calculations. Before doing this, Hide any Banner variable sets, variables you don't want to hard code, and any variables that are not needed in any tables, charts, or other outputs so that they are excluded from the new data file.
Next
Tips for Working Efficiently in Displayr
You can find more articles on how to improve document performance at How to Speed Up Displayr.