A lot of empty text nodes - I mean A LOT - performance issue

[neuronetio]

Describe the bug
Just check this repl https://svelte.dev/repl/902d4ccfcc5745d0b927b6db6be4f441?version=3.12.1

There are 22 000 empty text nodes that are really slowing down entire component on update.

Expected behavior
I know that those nodes are for a reason but maybe some virtual approach will be better?
Each node must be created updated and destroyed which takes a lot of time and memory when something change.

Severity
This behavior can lead users to leave svelte because they might not figure out what is wrong - code seems to be ok, but performance is really bad (22 000 extra nodes for 2 500 real ones :O ).
For me this is annoying because I must be careful and watch for those "extra" nodes that are appearing randomly in some circumstances.

[daliusd]

For something like this you should consider using https://github.com/sveltejs/svelte-virtual-list . Virtual list of course will not work for this specific problem, but that should give an idea.

[neuronetio]

Yeah, but I have a grid in my component with a lot of cells and those cells needs to be visible all the time - no scrollbar. REPL above is just simple example :)

[Rich-Harris]

@neuronetio can you share any numbers on the performance before/after #3642? we actually used comment nodes previously, but changed it to empty text nodes because it's less cluttered when you open devtools. If there's a noticeable performance impact then I guess we probably do need to revert it, though this does seem like an extreme case 😀. Maybe it could even be an option...

[marcus-sa]

@Rich-Harris comment nodes are way better for this usage.
There's a reason Angular is using them.

[daliusd]

I will give non performance reason why whitespace nodes is not good idea: https://codepen.io/daliusd/pen/rNNONVd

[shirotech]

+1 for comment nodes, also related #4423

[Conduitry]

Does anyone have any benchmarks for empty text nodes vs comment nodes?

[shirotech]

@Conduitry https://jsperf.com/empty-createtextnode-vs-createcomment/1

Comment nodes are slightly faster, but regardless of that comment nodes I think is more correct because it doesn't influence dom structure or styling/layout.

[gonchuki]

I think the discussion about text vs comment nodes derails the main issue at hand here which is the large amount of superfluous nodes being created.

Any slight difference between text vs comment nodes can shift around between browser engines or different versions of the same engine, but the creation of nodes that shouldn't be there is guaranteed to degrade performance in all environments.

[shirotech]

@Conduitry what would it take for comment nodes to be considered? Right now I'm just using a fork, as the app actually crashes with text nodes in IE11 if it was used in a WordPress environment (their emoji replacing function).