When to use createMemo? And when is it more overhead than it saves?

[mb21]

Solid docs say:

In Solid, you often don't need to wrap functions in memos; you can alternatively just define and call a regular function to get similar reactive behavior. The main difference is when you call the function in multiple reactive settings. In this case, when the function's dependencies update, the function will get called multiple times unless it is wrapped in createMemo.

Which makes sense. (Except for the "similar behaviour"... isn't it the exact same behaviour, assuming your function doesn't have side-effects?)

Coming from the React world, the advice is:

use useMemo when you have expensive computations that need to be memoized. Using it for every value in your component can actually hurt performance, as useMemo itself has a small overhead.

Now I'm wondering: does Solid's createMemo have a similar break-even point?

And if so, what's a good rule of thumb? Like if you have an array of 100 items and you filter on it and then access that five times... should you memoize the filter or not?

[atk]

In react, you would use memos not to compute results with the same parameters twice, this is a non-issue in solid anyways, because signals already have an equality check, so they wouldn't trigger computations if updated with the same value. If only for that, you can use plain functions.

The same also applies to solid if a value from a complex computation is used multiple times. However, it is even more useful if you have signals with frequent changes but only need to call the subscribers on certain changes, because then you can use createMemo as a reactivity filter to improve performance pretty effectively. For example if you have a volume meter for an audio signal, but only show 4 bars to represent the value, you could filter the updates so there are only updates at all if there are changing bars.

As createMemo is still rather lightweight, the break-even point to a normal function is already if you use Math.sqrt() in 2-3 places. It's even more effective as reactivity filter, though.

[mb21]

Thanks! Okay, that really sounds like you're better off erring on the side of using createMemo too often than too little...

But taking this idea to its extreme: why doesn't solid's reactivity system do what createMemo does for every reactive context? Sounds like it would improve the average case? Is it just to give the developer more control?

[atk]

you're better off erring on the side of using createMemo too often than too little...

Better avoid premature optimizations.

why doesn't solid's reactivity system do what createMemo does for every reactive context?

Solid already does what react's useMemo does for its signals (unless you add { equals: false } as second argument to createSignal), which is preventing reactive changes for the same values. The aim here is to work as effectively as possible by default while still allowing for precise control of the reactive behavior if you need it.

[mb21]

Thanks. btw, I quickly coded up your volume example and indeed, if you inspect the HTML with developer tools, and you wiggle a tiny bit on the slider, you can see that the text nodes displaying the dashes are always rewritten with the same value in the case without createMemo, but are only updated when necessary with createMemo: https://playground.solidjs.com/anonymous/5696821f-a19d-4840-9873-ab34f4f5e3f6

[cchaglund]

Better avoid premature optimizations.

Even if it's the right course of action 90% of the time? And what would be the harm in optimizing 100% of the time, even if occasionally premature? Sure, it might not be improving anything, but if it's not actually reducing performance/reactivity then what's the harm? Especially if the alternative is that 90% of the time when the developer is using signals without createMemo (which would be most of the time in the case of a novice) they incur performance degradation due to unnecessary reactive changes.

Seems like the best advice is essentially: use createMemo all of the time and only remove it if it's causing any problems(?)