Benchmarking

ivi

ivi is the only Virtual DOM library in this comparison and it’s fast. Unlike the others, ivi has Components in its Level 0 implementation. This is because Virtual DOM libraries use Components for change management. This means the most optimal implementation will have Components. It also means ivi scales well no matter how many Components. It’s only the move to per column Components where performance drop is at all significant. Still, this spread is impressive.

Memory pretty much follows suit. It isn’t until level two where the memory usage moves more significantly. We will be hard pressed to find another library that scales this well with Components.

lit-html

This performance does not scale nearly as nicely. I’m a bit surprised since lit-html doesn’t have any components. Admittedly the variance on ‘select row’ is problematic. I would have liked to get more consistent results but after countless reruns, lit-html would always spike on certain runs. Probably a limitation of the computer running the benchmark (a mobile Core i5) but it was the same constraints for all libraries. Still, the performance difference as you add Components is significant. ‘Create many rows’ and ‘append rows’ plummets as does ‘partial updates’. Perhaps memory will give more clues.

Yes. That is significant. Level two uses more than double the memory of the initial implementation. I’m not sure what about splitting multiple templates in lit-html does this but when we are making five Components per row in 1000 rows it definitely adds up.

Solid

Components were definitely an afterthought with Solid. It was always assumed it would be used with Web Components. However, the last two versions have brought major updates to Solid’s Components to bring them inline with features from other popular libraries. Solid does admirably here; Not as flat as ivi, but decent. It seems only the large data creates are affected here and most small changes aren’t impacted. This is due to Solid’s reactivity system being independent of Components. More on that later.

I had to do a double take when I first looked at these results. Additional Components barely affected Solid’s memory consumption at all. Seven Components or 5000, it’s basically the same.

Svelte

Svelte tags in as sort of middle of the pack. It isn’t as flat as ivi or Solid but it scales pretty proportionally. ‘Select row’ is still a pretty big drop. ‘Replace rows’ for some reason favors level one. This is not an anomaly. It consistently had better performance to split the row into a separate Component for that benchmark. My guess is due to the nature of its Reactive system being Component-based, separating off the Components means toggling only a single row reduces the amount of work. ‘Clear rows’ though is the place where performance degradation was the most noticeable. Memory is likely a concern, let’s check.

Yep. Svelte’s Components are heavy when it comes to memory. It goes from being the library with the smallest footprint in these tests to be the largest by a big margin. This is definitely something worth some attention in the future.