The most well-known type of calculation in Displayr is what's created by clicking the Calculation button in the toolbar. However, most advanced techniques and visualizations are also calculations. A document can almost always be sped up by reducing the number of calculations. 

This article contains a:

• Simple worked example
• An edge case where the strategy won't work: (Putting calculations into dropboxes does not give a performance advantage).
• Strategies for reducing the number of calculations
  • Use Displayr's inbuilt functionality
  • Use small multiples
  • Add data processing code into the R code of visualizations
  • Combine multiple calculations into a single table
  • Put controls on page masters
  • Deliberately create repetitive code
  • Use functions
  • Use Javascript variables

Simple worked example

Consider a document that contains the following six calculations:

cats = 2

dogs = 2

giraffes = 2

wombats = 2

platapi = 2

animals = cats + dogs + giraffes + wombats + platapi

This is surprisingly slow in Displayr. It takes about .8 seconds. If we examine the Inputs & Outputs, we see that each of the six calculations is taking about 0.4 seconds, but the first five can be done in parallel (if we haven't slammed the servers with lots of other calculations).

As mentioned in the title, we make Displayr faster by reducing the number of calculations. That's easy with this example, as we can replace the six with one:

cats = 2
dogs = 2
giraffes = 2
wombats = 2
platapi = 2
animals = cats + dogs + giraffes + wombats + platapi

And, we get a big payoff, with the time going from 1.2 seconds to 0.45 seconds. Why is it so much faster? If we view the raw R output,  we see that the total time executing the code was around 0.05 seconds, and the rest of the time was spent on something called Other overhead on R server (.39 seconds) and Time spent transferring data (0.01 seconds).

The overhead and time spent transferring data occur with every single R calculation. When we reduce the number of calculations, this time just disappears, which is why reducing the number of calculations is such a powerful approach. 

Putting calculations into dropboxes does not give a performance advantage

Most users use drop-downs to select things (e.g., tables, variables). However, when you click on a drop-down, it will often show a more advanced option of Enter a calculation or value. With this option, you can enter code into the box. In the example below, the code calculates the proportion of males.

As of the time of writing, at the back-end, Displayr treats this as an entirely separate calculation, so you don't get any performance benefit. However, the next section describes a strategy that can work in the same situation.

Strategies for reducing the number of calculations

The following strategies are often effective at reducing the number of calculations:

• Use Displayr's inbuilt functionality
• Use small multiples
• Add data processing code into the R code of visualizations
• Combine multiple calculations into a single table
• Put controls on page masters
• Deliberately create repetitive code
• Use functions
• Use Javascript variables

Use Displayr's inbuilt functionality

When we review documents that clients feel are too slow, the most common cause is that clients have written their code to do things rather than using Displayr's built-in functionality.

See Use Displayr's Built-In Features (Instead of Writing Code).

Use small multiples

Many visualizations in Displayr are, in the background, actually calculations (you can see if this is the case by looking for the Code button in Data > Attributes in Properties ). Where multiple such visualizations appear on a page, you can often replace them with a single small multiples visualization. 

See Use Small Multiples Instead of Lots of Small Visualizations.

Add data processing code into the R code of visualizations

Where a visualization is also a calculation, data processing code can be added to the R Code that creates the visualization.

See Adding Calculations into the R Code of Visualizations. However, before doing this, please make sure that you've first explored 

Combine multiple calculations into a single table

If you have multiple R Calculations (like conditional images/links/text, color-changing numbers, number visualizations, and dynamic texts) aligned in some way on the page, they can all be combined into one Table with Custom Formatting (Autofit) or by using the CreateCustomTable function in R. There are lots of examples on how to use these items, such as:

• How to Create an Autofit Table
• How to Align Values to a Visualization Using a CreateCustomTable R Table
• How to Create a CreateCustomTable R Table of Images
• How to Customize Fonts in a CreateCustomTable R Table

Put controls on page masters

Often, documents contain the same controls on multiple pages. For example, each page may contain a listbox showing ages. Then, this listbox needs to be connected to multiple distinct other calculations and R variables. A much better design is to instead move the controls to a master page, which reduces the number of controls and can also reduce the number of calculations and variables required to refer to the control. See How to Use the Same Control on Multiple Pages.

Deliberately create repetitive code

Let's say you have three calculations, where the first one is computed, and then calculations 2 and 3 are computed using the first one as an input. It is often the case that it will be more efficient to include the code from the first Calculation at the beginning of the second and third Calculations, and then remove the first Calculation. That is, the reduction in time achieved by reducing the number of calculations will make up for the duplication of code. This is partly due to Displayr performing things in parallel and partly due to the overhead associated with calculations.

Use functions

An even better strategy than creating repetitive code is to abstract the common code by writing a function, and having that function appear as a separate calculation used by the other two calculations. The key thing to appreciate about doing this is that while you still have three outputs, the function itself will be cached, so it will not really affect performance.

Hide information in attributes

Consider the situation where you have a calculation that computes one table, tbl and some text summarizing the table, dscr. The orthodox way of dealing with this in R is via a list: out = list(table = tbl, description = dscr). However, if you want to hook the table up to a visualization, you would need to create a separate calculation with code out$table, and refer to this in your visualization.

An alternative way of doing the same thing is via attributes. For example:

attr(table, 'description') <- dscr
table

This returns the table which can then be referenced directly in a visualization without any need for an intermediary table. The description is then extracted by referring to attr(table, 'description') in R code.

Use JavaScript variables

While R variables are the most flexible and powerful type of creating custom variables, JavaScript variables are always much faster and should be used if an R variable is a bottleneck (the exception to this rule is for filter variables).

Next

Examine the Calculation Timings in the Raw R Output

How to Perform Mathematical Calculations Using R

How to Perform Mathematical Calculations on Tables

Examine the Calculation Timings in the Raw R Output