luwes / js-diff-benchmark Goto Github PK

$ npm test

> [email protected] test D:\doc\prog\learn\js\vdom\js-diff-benchmark
> node --expose-gc src/bench.js

D:\doc\prog\learn\js\vdom\js-diff-benchmark\src\utils.js:29
    mutations.push(`remove: drop(${oldNode.textContent})`);
                                           ^

TypeError: Cannot read property 'textContent' of undefined
    at Dommy.container.removeChild (D:\doc\prog\learn\js\vdom\js-diff-benchmark\src\utils.js:29:44)
    at module.exports (D:\doc\prog\learn\js\vdom\js-diff-benchmark\libs\spect.js:20:18)       
    at create1000 (D:\doc\prog\learn\js\vdom\js-diff-benchmark\src\utils.js:82:14)
    at D:\doc\prog\learn\js\vdom\js-diff-benchmark\src\bench.js:75:20
    at Array.forEach (<anonymous>)
    at Object.<anonymous> (D:\doc\prog\learn\js\vdom\js-diff-benchmark\src\bench.js:58:6)     
    at Module._compile (internal/modules/cjs/loader.js:1147:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1167:10)
    at Module.load (internal/modules/cjs/loader.js:996:32)
    at Function.Module._load (internal/modules/cjs/loader.js:896:14)

TY :)

Results seems quite off on my laptop (Dell XPS i7) so I wonder if there's some update needed, as I can see consistently udomdiff faster than others as overall usage.

Replace is slightly different than clear and insert as it has to first realize that it can't keep anything that's there. I thought I saw it before maybe? Was it removed?

The new random test #5 makes snabbdom fail the assertion.

Related issue luwes/sinuous#98

At the moment results could be skewed quite a bit from run to run.

Ideally each test should run a minimum of 3 times, randomize library order at least, and take some average

The number of operations is way too big.

Seems the script used in the benchmark is broke.
https://johnresig.com/projects/javascript-diff-algorithm/

cc @jeresig

ivi has an improved reconciler after localvoid/ivi@ab63ddb

related: localvoid/ivi#20 (comment)

Pretty impressed with how this script performs only the swapping at the moment requires way more extra operations than is needed.

Would be nice to see this fixed with minimum size added.

  // insert
  diff(parent,[], [e1,e3,e5], null);
  diff(parent,[...parent.childNodes],[e1,e2,e3,e4,e5], null);
  parent.childNodes // e1, e2, e3, e5, e4

  // prepend
  diff(parent,[], [e4,e5], null);
  diff(parent,[e4,e5],[e1,e2,e3,e4,e5], null);
  parent.childNodes // e4, e5, e1, e2, e3

That is so regardless of the last argument.

Hi I would like to see domdiff in here too.
Thought about creating a PR but do not want to be rude.

Would be cool
https://github.com/Automattic/cli-table

Here's jsperf template for insights:
https://jsperf.com/insertbefore-vs-udomdiff-vs-snabbdom-vs-spect/1

2 assertions are failing for Snabbdom

The test at the moment measures the algorithm but it doesn't correlate to real life where the number of DOM mutations can have a bigger impact than the algorithmic logic.

It would be interesting to see if giving weight (take more time) to these operations could simulate a real browser environment better.

Probably better start using playwright or puppeteer at that point
https://github.com/puppeteer/puppeteer
https://github.com/microsoft/playwright

Another interesting test to put in the mix:

diff(
    parent,
    parent.childNodes,
    parent.childNodes.sort(() => Math.random() - Math.random()),
    get,
    parent.lastElementChild
  );

Warning

snabdom here fails 1 out of 3 times so that tests should likely be put in try/catch and warn in red the test broke/didn't work.

You can give it a try with 1000 rows already, launch it few times and see snabdom fall.

I might file an issue in there though ... or maybe they know already.

I think it is good to know. And it is definitely a consideration for libraries in general. But I wanted to point out from a reactive standpoint I think this test doesn't matter for the list reconciler very much. Nested updates unless they replace the whole element avoid the list reconciler (which is why reactive is fast). From this perspective I think that makes udomdiff still the better choice for a reactive library?

EDIT: I see replace is the big one. Probably because doesn't do the shortcut there. I wonder how much code that'd take to remedy. And the scaling of append. Interesting. That deserves further investigation.

As I understand, results published in README are results from running tests on node.
After running benchmark multiple times on Chrome 89 with 6x CPU throttling I barely can get 3% difference between stage0 and udomdiff reconcilers, while results in node (and README) look like there is almost x3 slowdown difference between them.
Results between 5 of 6 libraries are very minimal, with only heckel having noticeable hit.
I would recommend to use only browser results, they do not change the winner, but can ease bad representation of other libraries. Also I think results in the browser are much more stable, especially with throttling, without hunting for randomized milliseconds in node.