Displayr runs in a browser, so it has built-in limits on table size. Each cell in a table holds one or more data points — for example, a cell showing three statistics counts as three data points, not one. Very large tables containing more than 3000 data points are truncated to prevent the browser from slowing down or crashing. You might see "excess rows removed" at the bottom and/or "excess columns removed" at the end of the table. The full data table is still available when you export it to Excel.
Even within those limits, though, tables can still be slow to calculate and display. Sometimes there are requirements on table creation and formatting such that a slow table is simply unavoidable. But in many cases, there are practical steps you can take to fix the root cause.
Tables can take a long time to compute for various 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. To reduce load time, you can reduce the grid size. Consider splitting the grid into smaller variable sets (How to Split Grids by Rows or Columns in Displayr) and/or creating a smaller Binary-Grid (How to Combine Separate Questions into a Grid in Displayr) containing fewer variables.
- The speed can also be compounded by the number of statistics shown on the table. To reduce load time, ensure the table contains only the statistics required, or create multiple tables showing different statistics.
- The number and complexity of Rules applied. Rules get applied after Displayr creates the table. Rules are applied individually in the order they appear in the Rules tab. To reduce time, include only the necessary Rules and avoid adding the same rule multiple times.
- The table has column comparison significance testing enabled. For a grid with 20 rows and 20 columns, each column is compared pairwise against the other 19 columns, requiring 190 tests per row. Across all 20 rows, that's a total of 3,800 tests. To reduce load time, consider using arrows, font colors, or arrows-and-font-colors tests instead — these run far fewer tests (400) and load faster than column comparisons.
- You are using banners when there is no need. For example:
- If there is only one question in your banner, it will generally be much faster to choose 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 input variables and then compute the variables prior to computing the table. To reduce load time, create a Separate Data Preparation Document and hard-code the variables into the data set before starting your analysis.
- 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 exporting 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 it 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.
UPCOMING WEBINAR: From Thousands of Tables To One Clear Story: using AI in survey analysis