marko-js isomorphic ui benchmarks

[artalar]

Hi! Check this benchmarks, the Preact is one of the slowest. Why is it so?

I was running the bench on my middle-perf smartphone (Samsung a40) and getting even worst results:

MacBook Air 2017 took the Preact down too:

Are the benchmarks correct? Is example code some critical case for the Preact?

[JoviDeCroock]

Hey,

Thanks for bringing this to our attention, there are a few things we have to consider here while evaluating this benchmark, firstly, the way keys are used isn't the best, it uses the mapped index rather than the unique identifier for the item. https://github.com/marko-js/isomorphic-ui-benchmarks/blob/master/benchmarks/search-results/preact/components/App.jsx#L20

This means that if an item is reused on a different position the dom can't be reused due to the key being different, this is basically a hint to our reconciler that it can't be reused, which in itself is already a performance drop.

Secondly, the version used for Preact predates the strict-equality improvements that were introduced around 10.4/10.5, this in itself improves performance when it sees two strictly equal old- and new vnodes. https://gist.github.com/JoviDeCroock/bec5f2ce93544d2e6070ef8e0036e4e8

Thirthly, we are aware that in long lists we have a few issues in our current diffing algo, which is something we aim to fix in our current reconciler rewrite.

Thanks again for bringing to our attention, maybe we can integrate this in our bench suite.

[marvinhagemeister]

Thanks for sharing these! The first search-result benchmark is a purely SSR benchmark. It's interesting to see the different approaches chosen here. The reason marko wins there is that it precompiles all components to strings which just need to be concatenated together at runtime. The benchmark is essentially a giant template, with barely any components.

// Pseudo marko, grossly simplified:
const a = componentA = {
   html: `<div class="foo">...</div>
}

const b = componentB = {
   html: `<div class="bar">...</div>
}

const html = a.html + b.html

I've been wondering myself if Preact should move to become more of a compile time framework in the future. Property normalization, like casing, makes up roughly 40% of the work and it could be done once during compilation.

That said I spotted a regression in preact-render-to-string which makes it slower than it should be. I'll release a new version shortly 5.1.13. The fix brings it up to par to React's SSR renderer in that benchmark.

[artalar]

Ok, thx for answers!