3 ms·
> What would happen if the view functions in elm by default were lazy? `lazy` incurs a performance penalty not in memory but in execution steps, due to having
by _greim_ 5y ago
> What would happen if the view functions in elm by default were lazy?
`lazy` incurs a performance penalty not in memory but in execution steps, due to having to do a deep-equality comparison on the prev/next view inputs in the underlying JS. Enabling such a check globally would, on balance, slow everything down. Only if the work of running the view exceeds that small penalty, would you want to use it strategically here and there, hence the reason it's opt-in.
Even if the Records and Tuples proposal[1] lands and Elm gets refactored to use it internally, thus allowing `===` comparisons in the underlying JS instead of deep-equality, it's unclear whether enabling it globally would be good or bad, simply because the JS engine itself would presumably still be doing some kind of deep-equality check behind that innocuous-looking `===` operator. When the time comes I'll be curious to see if there's any progress on that front.
[1] https://github.com/tc39/proposal-record-tuple https://github.com/tc39/proposal-record-tuple
- Skinney 5y agoIt’s a shallow comparison, not deep. But yes, there is both computational and memory overhead when using Html.Lazy
- matsemann 5y agoBut isn't there also that when not using lazy? Instead of checking model equality, elm runtime now has to check shadow dom equality and calculate dom operations to apply. My thought is that my idea isn't obviously worse.
- Skinney 5y agoYes, but lazy adds to that work. So for views that will pretty much always need to be re-rendered (because the only changes are at the bottom of the view hierarchy) then wrapping them in lazy will only slow down the dom recalculation.
- _greim_ 5y ago> It’s a shallow comparison, not deep. Interesting. I thought it was doing a deep comparison, but apparently it uses reference equality, and thus shallow.