Improve performance by checking that the data changes

[PaulBGD]

Basically, anything that touches the DOM is slow. Because if that, this PR checks if any data changes before touching the DOM.

You can see the performance by comparing the dbmonster built with this PR to the normal one: https://svelte-dbmonster-perf.surge.sh/dist/index.html

Here are some screenshots from my late 2012 i5 macbook pro:

The dbmonster based off this PR will jump up to 600fps, but the regular dbmonster doesn't go past 60fps. I'm not sure why the dbmonster based off this PR has such sudden fps jumps (although it doesn't drop below 60 for me.)

[PaulBGD]

After testing this in chrome, it seems that this only has such a big performance improvement for Firefox. I guess chrome must internally check if it changed and firefox doesn't.

[Swatinem]

Depending on the expression, snippet might be pretty long (codesize-wise) and also be slow (think computed accessors).

I was thinking about creating a helper for text nodes (and later also for attributes, see #25 ) that does memoization and comparison internally.
That textnode helper might have the same api as fragments, with update, mount, and detach functions.
What do you think about that?

[Rich-Harris]

Wow, that's an impressive speedup on Firefox. Memoizing helpers is definitely worth exploring — there might be an overhead involved (truthfully I have no idea) so maybe the right move in the meantime would be to assign ${snippet} to a tmp variable (which could be reused) and comparing that to last_${name}?

[PaulBGD]

Good idea about assigning ${snippet} to a temporary variable.

[PaulBGD]

So since I'm finally on a windows computer I decided to try this on Edge.

Regular:

PR:

The FPS isn't very different but the change between view update time is huge.

[Rich-Harris]

I implemented the temporary variable thing, and extended this to {{{triples}}} and attributes

[PaulBGD]

Looks good.