Update 10th row: minimum operations about udomdiff HOT 7 CLOSED

btw, this project has a license, if you copy and paste code from here, please put the license on top of each file (i.e. Dommy)

from udomdiff.

I used to use snabdom, but it was failing with some case and it wasn't providing custom items in the list (wires) so it's not an option for any of my libraries, as fragments would fail at diffing, which is not the case for both udomdiff and domdiff.
Will look at the rest once on a PC

from udomdiff.

To start with, it'd be nice if you could file a PR in here when you find issues with some part you copied and pasted ... as example, I had a bug in _removeChild 'cause it was splicing from childNodes which was pointless, but you fixed it, without letting me know 😢

secondly, everything is fine. If you console.log(parent.oeprations) after the update every 10th row part, you'll see:

[
  'removeChild(0)',
  'insertBefore(0!, 1)',
  'removeChild(10)',
  'insertBefore(10!, 11)',
  'removeChild(20)',
  'insertBefore(20!, 21)',
  'removeChild(30)',
  'insertBefore(30!, 31)',
  'removeChild(40)',
  'insertBefore(40!, 41)',
  'removeChild(50)',
  'insertBefore(50!, 51)',
  'removeChild(60)',
  'insertBefore(60!, 61)',
  'removeChild(70)',
  'insertBefore(70!, 71)',
  'removeChild(80)',
  'insertBefore(80!, 81)',
  // etc, etc ... 
]

Basically, instead of updating the node content (the actual js-framework-benchmark case you changed using a new node instead of new value) you end up not having the old node anywhere in the new list, so you pass here and then you pass here, as the long sequence is pretty high so it makes sense to keep inserting before until we reach that sequence (in this case we simply insert before 1 node, then it's a fast-forward until the next 10th).

As Summary

There's nothing wrong in any of the libraries, as long at these don't break, and produce the expected layout.

An efficient diffing algorithm would tend to be O(log n), meaning you cannot have granted amount of operations the way you'd do manually, but you have granted a close to optimal amount of operations.

As example, replacing 1000 rows can be a replaceChild per each item, but in order to do so, you need to know that the item you are replacing is not somewhere else in the already live list, otherwise that item might be found in two places which is not possible on the DOM.

Most algorithm here would simply remove items that won't be live, and move forward, appending all remaining items at the end.

This is a drop all + insert all procedure that cannot be counted as faulty, as it's actually what the DOM needs to do in order to materialize the new state in the UI, even if you replaceChild instead, because the amount of moved nodes (inserted & removed) is the same 👋

from udomdiff.

P.S. same goes for each 10th: replacing groups 2 operations at once, but behind the scene it removes one from the tree and inserts a new one in the tree, even if it's the same spot. Anyway, great to see snabdom fancy dance gets the minimal amount of API calls, if only they would accept fragments, it'd be fun comparing for real, as all the get(...) calls in udomdiff might be the reason it's slightly slower.

from udomdiff.

P.S.2 ... regardless, this is the result on my laptop, udomdiff wins in perf 🎉

if you want to see other competitors, check https://github.com/krausest/js-framework-benchmark out

from udomdiff.

Sorry, last clarification:

• the file you thought was used as benchmark was actually for debugging operations, there are indeed no expected amount of operations in the assertion, because it's obvious each algorithm might shine somewhere and fail somewhere else. It was also created merely to test udomdiff could be integrated in the js-framework-benchmark repository, as domdiff is already there (and so is uhtml but ... not raw udomdiff yet)
• because of how algorithm works, and how the DOM works itself, you should likely remove that misleading failing at counting because all operations are expected, not bugs, to it's a bit of a shameful table for no reason.

If I were you, I'd simply explain that some library might do a minimal amountof API calls, but that doesn't mean that:

• other library are faulty
• that library that does such minimal amount of operations is faster ... and you see the bench indeed prove that on my machine 😉

Anyway, thanks for the report the filed issue 👋

from udomdiff.

thanks for the replies! I'll have a look soon, you're right they're indeed not really failing. I'll remove that later.

I know about js-framework-benchmark, my lib Sinuous is on there too.
your simple benchmark just seemed better to quickly test the diff algorithm.
I'm trying to refactor sinuous/map to be smaller but at least be equally fast.

sorry about not reporting the childNodes issue, it was yesterday late at night.

ah yes, the fragment support is definitely a plus but that shouldn't be too hard to add I imagine.

from udomdiff.