search

luwes / js-diff-benchmark

Simple benchmark for testing your DOM diffing algorithm.
66 stars 5 forks source link

Add random test #5

Closed luwes closed 4 years ago

luwes commented 4 years ago

Fixes #2

Interesting one.

stage0 always results in the least amount of operations. snabbdom assertion is failing. udomdiff is the fastest for sure, even though # operations is higher than stage0.

https://github.com/luwes/js-diff-benchmark/blob/9784a116a6a9e05eb3cb43197f6858ad65d3f668/src/bench.js#L72-L72

cc @WebReflection

WebReflection commented 4 years ago

udomdiff is the fastest for sure, even though # operations is higher than stage0

I think I've already explained why: replaceChild costs basically as much as removeChild and insertBefore as the DOM operations behind the scene are the same 😉

the algorithm to figure out those operations matters more than the number of operations

luwes commented 4 years ago

did you verify? stage0 doesn't use replaceChild

the algorithm to figure out those operations matters more than the number of operations

I'm not so sure about that, is that true? DOM mutations are the most expensive part no

WebReflection commented 4 years ago

did you verify?

nope, I was just guessing ... but ...

stage0 doesn't use replaceChild

so in a shuffled deck, the minimum amount of operations is to insertBefore while moving the right nodes around, 'cause they are all live nodes ... yet the concept is the same: the algorithm matters more than the amount of operations. If you traverse many times to find the perfect amount of operations it costs more than the udomdiff approach, 'cause it never needs to traverse the lists more than once.

I am curious to see what they do though, will check (eventually)

WebReflection commented 4 years ago

OK I had a look, it does a bit too much, imho, and it accesses nextSibling a lot, while mutating the DOM, which might cause slowdown, as it's an API getter. I believe this test falls into last functions based utilities parts too, so I think it can hardly compete in terms o raw perf.

that being said, having a slice().reverse() benchmark in the mix (i.e. sorted table up and down) might be interesting, as randomized rows, after a sort operation, or a sort up/down, are more real-world benchmarks for these kind of libraries, than few changes with long same sequences around, which are never cryptic in the real-world.