Eek! Performance Problems

Things to watch out for ...

Using `=` On Big Structures¶

Reagent uses = to compare the previous value of a prop with the new value of that prop, when it determines if a component needs rerendering. Make sure you have a good understanding of this.

In the worst case, if those props are big data structures which differ only in some tiny, leaf aspect, then a lot of CPU cycles will be spent doing the = comparison only to eventually work out that, indeed, the answer is false.

This problem is exacerbated when components return a lot of hiccup, because lots of hiccup normally means lots of = work. Any rerender with those characteristics could end up chewing a lot of CPU cycles.

An Example Of This Problem¶

Imagine you were rendering a 19 by 19 "Go" board.

And imagine that you have a high level board renderer component which creates hiccup for the 361 subcomponents (19 x 19 grid), and that it provides 3 props to each child:

grid x coord
grid y coord
a chunk of data representing the current game state, from which each of the 361 individual grid components is expected to extract the data they need to render their grid position.

This arrangement could be slow.

First, you have a parent component returning hiccup for 361 sub-components and that's a lot of hiccup!! Sure, it might not be much code - just a couple of nested for, but the hiccup data structure built will be substantial.

Second, after the board renderer returns all this hiccup, for every one of those 361 sub-components, Reagent must then check the 3 props to see if they are = to the value last rendered (to determine if they, in turn, need to be rerendered), and the comparison on the 3rd prop (game state) might be deep and expensive. Worse, we do the same expensive check 361 times in a row, and every time we get a false (because games state is not = to last time).

Third, because Reagent gets 361 falses, it will further rerender all 361 sub-components even though 360 of them produce the same hiccup as last time - only one position in the grid has changed.

So, when a new stone is placed on the board, and the game state changes, that triggers a large amount of unnecessary calculation, just to figure out that there's only a rendering change at one point in the 19x19 grid.

So, that's how you can get a performance problem: lots of hiccup, mixed with time-consuming = tests on big props.

Solutions To This Problem¶

The solution is to not do the unnecessary work. Duh!

Produce only the hiccup that is needed. Don't unnecessarily pass around big complicated state in props, unless you really need to.

In the Go example described above, for each new stone placed, only one point in the Go board actually needs to be rerendered, and yet our code asked Reagent to chew a lot of CPU to figure that out.

These kinds of tweaks would improve performance:

don't give the entire game state to each of the 361 subcomponents and then ask them to extract what they need. Instead, give each just the state it needs, and nothing more. That will make the = process faster. It will also allow for Reagent to figure out that 360 of the subcomponents have the same props as last time, and don't need rerendering. And, so, only one sub-component will be rerendered when the parent "board level" component rerenders.
Also, could you render the board row by row? So that less hiccup is produced by any one component? Can those rows subscribe to just the data for their row, so they only rerender when the row-data changes; they only generate hiccup when something really has changed?

3. Are you Using a React `key`?¶

Correctly using React keys can also make a huge difference to performance.

Some resources:

4. Callback Functions¶

Consider this div:

[:div  {:on-mouse-over  (fn [event] ....)  }   "hello"]

On every render, that :on-mouse-over function will be regenerated, and the one generated "this time" will NOT test = to the one generated "last time". It will appear to be a new function. React will conclude that it must replace this event handler.

Most of the time, this is not an issue. But if you are generating a LOT of DOM this small inefficiency can add up.

To work around the problem, lift the function generation out of the render. Use a Form-2 function like this:

(defn my-component 
   []
   (let [mouse-over-cb  (fn [event] ....)  ]      ;; created once 
      (fn []                                      ;; rendered many times
         [:div {:on-mouse-over  mouse-over-cb}]))

Now, React will see that mouse-over-cb is the same as last time. It won't think the event handler has been replaced.

But like I say, don't be too paranoid about this, it is unlikely to be an issue unless you have something like a table with a lot of identical cells.

Use The Trace, Luke¶

If you want to know exactly what's going on, get some X-Ray vision from the official tracer. See exactly what subscriptions are running, what views are getting re-rendered, etc.

You may be surprised by what you see.