Riot: Riot is slow in a benchmark

[niutech]

Riot scores very low in the JS framework benchmark. This is in contrast to Riot goal of being fast and minimalistic. Is the benchmark code suboptimal or is it normal for Riot?

[avimar]

Summary of my attempts so far:

• I tried removing functions from the row-tag for less repetitions, but that didn't help.
• I tried removing the "double passing" of the each and data=, but that didn't help.
• I tried updating to riot@next, but it didn't show me _anything_, I don't know why.

[GianlucaGuarini]

I will check the example asap and verify what's wrong there.

[GianlucaGuarini]

Form a quick look it seems that the riot code is written by someone who has no idea about how to use our framework. Useless query selector on any mount event, invalid syntax, useless update events will not help riot in this benchmark I will see whether I could do a pull request. In any case it would be fair to ping us before publishing benchmarks without even having read the framework doc (and in our case it's not a lot)

[GianlucaGuarini]

I took time for a pull request. I can not see the results compared to the other frameworks because this benchmark is really badly designed (it needs hours to get the results) but at least riot is properly implemented
https://github.com/krausest/js-framework-benchmark/pull/29

[pongo]

New results table (column riot v2.5.0-2). Almost the same.

[GianlucaGuarini]

@pongo so I guess it's better to use another framework or vanillajs riot seems to be too slow

[niutech]

Do you have any ideas why it performs poorly compared to react and
other frameworks? Thanks!

[GianlucaGuarini]

Riot renders updates and moves dom/components nodes. This is a lot heavier than just rendering and parsing strings like React, Vue and Angular do. We have already discussed several times this topic https://github.com/riot/riot/issues/484 . Our users seem to prefer reliability over speed (although loops will be totally refactored in [email protected] and are on the top of our prio list) because in this way riot can be used with third party libs without any problem because it just uses and keeps the original DOM nodes created. If you need to render 10.000 rows with javascript you should consider either vanillajs, another framework or a good doctor.

[5angel]

@GianlucaGuarini

[...] or a good doctor

sick burn 😂👌

Btw, shouldn't no-reorder speed up things like that?

[GianlucaGuarini]

@5angel It seems it didn't but we are all aware of it..but your pull request will solve the issue right? 😄

[localvoid]

Riot renders updates and moves dom/components nodes. This is a lot heavier than just rendering and parsing strings like React, Vue and Angular do

WAT? All this libraries are creating and updating dom nodes with createElement, insertBefore, setAttribute, etc. React 0.14 was the latest version that used strings to create dom nodes. And creating nodes with strings won't be faster in all browsers except IE/Edge.

[GianlucaGuarini]

@localvoid react uses strings + expressions updates https://jsfiddle.net/gianlucaguarini/69z2wepo/50446/ that's why every javascript lib should be wrapped to handle stuff in "the react way"
I am having exactly the same issue with vue (vue + swiper) in a really big project.
Riot just plays well with any other js library because it tries to stick as closer as possible to the "normal javascript" way to update the DOM. We have performance issues on huge lists and we are on it hold on

[GianlucaGuarini]

My example updated https://jsfiddle.net/gianlucaguarini/82cwv4uk/ using unique react keys. In this case you need to explicitly define how your DOM nodes should be reordered even if you already know it from the Array indexes of your items 👎

[localvoid]

In this case you need to explicitly define how your DOM nodes should be reordered even if you already know it from the Array indexes of your items

You either have keys that can uniquely map items in array to ui nodes, force users to preserve identity of objects stored in array, or you can override array methods and store log of operations, then compose it and apply changes. If you are using just array indexes to uniquely map items, I guess you have way much bigger problems than performance.

[dogada]

BTW, is it possible to implement with Riot following React's functionality:

If you call ReactDOM.render() on a node that already has this server-rendered markup, React will preserve it and only attach event handlers, allowing you to have a very performant first-load experience.
https://facebook.github.io/react/docs/top-level-api.html

[babakness]

I saw this example:

https://crisward.github.io/riot-grid2/

100,000 records. Seems pretty fast to me--faster than 4 seconds cited to create just 10,000 rows in their bench. But perhaps my laptop is faster? That or the algorithm here is optimized.

[localvoid]

100,000 records. Seems pretty fast to me--faster than 4 seconds cited to create just 10,000 rows in their bench. But perhaps my laptop is faster? That or the algorithm here is optimized.

> document.querySelectorAll("*").length
< 386

lol, almost 100,000 :)

[babakness]

@localvoid All the better, this means 100,000 records aren't loaded into the DOM unnecssarily. This is far superior to rendering 100,000 records to the DOM with _any_ framework. Its easy to do with vanilla JS. Try both side-by-side and see which leads to better UX.

Technically I believe it would be in excess of 3 million DOM elements if done without any clever techniques.

[localvoid]

@babakness it is easy to do with almost any ui library. What is the point to compare implementation with occlusion culling against implementation without it?

[babakness]

Good point and I agree. Sure Riot should optimize but its not a deal breaker either.

[niutech]

Looking at the numbers, riot has the worst 18x slowdown in appending rows. Is there a way to improve this a bit?

[aMarCruz]

The benchmark is mixing apples and oranges...

Example: I know inferno and it is a low-level framework to construct a tree (like vdom) that can be used by others tools like riot, but does not cares about state, scope, css injection, real time expression evaluation, etc.

However, issues with the performance of the loops are a reality, especially when I see the comparison against bobril for example (limited and specialized framework, but one of the best imo).

[trueadm]

@aMarCruz Inferno isn't that low-level. You can use parts of it in that way, otherwise it's just the same as React. In fact, you can use it in existing React projects using inferno-compat. It's fully virtual DOM too.

There is no reason why Riot can't improve its performance by looking at other projects and researching on their methods of gaining decent performance. Performance is a big deal, especially on mobile, where performance is about 10-15x slower than desktop machines on some Android devices.

[GianlucaGuarini]

@trueadm thanks for inferno and for your detailed explanation.
I think this issue is just invalid because:

1. We know there are perfomance issues in riot since [email protected] http://riotjs.com/faq/#any-future-plans
2. Performance improvements are scheduled for [email protected] since 19th March https://github.com/riot/riot/issues/1694
3. We are working already on a solution https://github.com/riot/riot/tree/feature/clean-each so please hold on
4. This kind of issues don't help us solving problems we already know but they are just noise/pollution

With that said if anyone would propose constructively a solution or make a patch to help us on this issue, pull requests are really welcome.
From this moment on I will not be interested in answering or participating to any other performances related issue because I feel like wasting my time here

[niutech]

I would say it's a valid issue from a user perspective, but will be
addressed in version 3.0. Then it should be closed as fixed.