I was looking at the http://www.stefankrause.net/js-frameworks-benchmark6/webdriver-ts-results/table.html benchmark and why is that Hyperapp near last (for the 5 frameworks I selected) for so many operations? Elm is the worst. Wondering when optimizations they have made?
Note: I also dont know how common these operations are versus other operations where Hyperapp shines. I think that's the issue with these benchmarks :)
append-rows
Remove-row
Swap-row
Select-row
partial-update
rajaraodv
All 26 comments
Those examples don't show hyperapp as bad at all If I interpret them correctly. The main number is the slowdown, smaller is better. The last one (partial updates) for example has hyperapp in a tied second best.
But there's also a problem with the comparison because some of those examples are using keys and some are not. Non keyed will probably always be faster than keyed (in any framework) so we're comparing our best case to the worst case of (some) other frameworks.
zaceno
on 18 Sep 2017
On the plus side, HA has one of the fastest startup times 😄
okwolf
on 19 Sep 2017
the keyed and non-keyed results have been split up for some time now.
the current WIP results table is here: https://rawgit.com/krausest/js-framework-benchmark/master/webdriver-ts-results/table.html
you guys should submit a keyed impl ;)
leeoniya
on 19 Sep 2017
(I'll repeat myself here. :smile:)
Those benchmarks should be the last thing you're looking at when choosing a framework/lib. They're highly irrelevant for most use-cases.
If you're opening a page with a 10k-row atble, I'm pretty sure you'll first wait 10 seconds to get data from the server. Who cares if rendering will be 1 or 1.2 seconds after that...
lazarljubenovic
on 19 Sep 2017
@lazarljubenovic More like 200ms~400ms.
jorgebucaran
on 19 Sep 2017
the 10k bench is certainly ridiculous (it creates ~80k nodes), plz dont do that to your users, regardless of framework. most complex UIs have < 5000 nodes. grids/tables get you there pretty fast though.
leeoniya
on 19 Sep 2017
There's a new round of benchmarks out now. Interesting how these two are right next to each other overall:
okwolf
on 23 Nov 2017
@leeoniya
you guys should submit a keyed impl ;)
It's finally in! And not terrible 😄!
http://www.stefankrause.net/js-frameworks-benchmark7/table.html
zaceno
on 23 Nov 2017
@zaceno IMHO our ranking near the middle means that we shouldn't be worried about performance as our top priority right now 🤷♂️
okwolf
on 23 Nov 2017
@okwolf We'll improve a bit, but first let's get the router and co. out of the way.
jorgebucaran
on 23 Nov 2017
@okwolf I agree!
zaceno
on 23 Nov 2017
Our bottlenecks seem to be partial update, remove row and append rows to large table
Swizz
on 23 Nov 2017
Just my own subjective observation here, compare these two examples:
http://game-of-hyperlife.surge.sh/
https://codepen.io/hyperapp/pen/zNxZLP?editors=0010
In the game of life there is a notable lag when you activate the pixels..
cjh9
on 28 Nov 2017
@cjh9 That's CSS. https://github.com/applefreak/hyperapp-game-of-life/blob/c4c9d24efe34653159164051993259fe1952dc3b/styles/app.css#L55
Please consider doing some researching before posting.
jorgebucaran
on 28 Nov 2017
@JorgeBucaran Oh, I see, sorry will do!
cjh9
on 28 Nov 2017
Do we have any proposals on the table for improving performance, or will this issue just stay open forever?
okwolf
on 17 Dec 2017
i suspect you guys are gonna run into having to address your perf vs lib size priorities to make meaningful headway here. all performant & correct algorithms [that i know of] are bigger than all of hyperapp :)
leeoniya
on 17 Dec 2017
@leeoniya interesting perspective. I would say the tradeoff when it comes to libraries is a little more like:
Small, fast, general purpose - pick any two.
I would like to think that by keeping Hyperapp simple (immutable state, functional components, no synthetic events, etc) we could hope to be both small _and_ fast. But we shall see...
okwolf
on 17 Dec 2017
@leeoniya I am confident I can improve the current algo just a bit (prefix/suffix trimming) in less than +50/100 bytes. And not because it makes a huge difference in real apps (it really does not), but for the challenge and good old js-framework-benchmark boys club :)
@okwolf Same here, but we could do slightly better with little cost. I really wish I could work more on Hyperapp. 😞
jorgebucaran
on 17 Dec 2017
Closing in favor of https://github.com/hyperapp/hyperapp/issues/499
jorgebucaran
on 17 Dec 2017
but for the challenge and good old js-framework-benchmark boys club :)
what qualifies as "real apps" is uncomfortably subjective, while relative performance of libs is not. for serious codebases, 2kb vs 10kb lib size is absolutely meaningless compared to runtime perf without horrible edge cases.
leeoniya
on 17 Dec 2017
I'll echo your own words here.
The 10k bench is certainly ridiculous (it creates ~80k?? nodes), please don't do that to your users, regardless of framework. Most complex UIs have < 5000 nodes. Grids/Tables get you there pretty fast though. — @leeoniya
With regards to:
...what qualifies as "real apps" is uncomfortably subjective...
I think NASA, Apple, Playstation, LinkedIn, Travis, Vine make real apps and some or all of their apps are built with ember, which is slower and substantially heavier than Hyperapp.
Keyed Results
Non-Keyed Results
It was never my goal to science the life out of VDOM, but I've learned quite a bit in the process of building this frameworks and even when matched against the excellent libraries featured on that bench, like yours, we don't suck at all!
Now that the dust has settled around here and 1.0 is just around the corner, I want to see what improvements I can bring to the table that do not take us too far away from our original proposition.
I hope I can find time for this soon, it's at least on my ToDo for the first quarter/half of 2018. 💪😄
See also:
jorgebucaran
on 17 Dec 2017
right, the bench is not meant to be realistic. we'e actually considering moving it to be even less realistic just to get rid of measurement fluctuations around extremely light workloads.
it's certainly possible to build fast apps with Ember, or jQuery, or Backbone. but you have to start optimizing your app early and often. with fast frameworks, you can focus more on writing code and less on worrying whether or not a lib is gonna throw a random wrench at you to solve in some convoluted way under a time crunch.
a huge asterisk to all of this, is that js-framework-benchmark runs on a fast laptop. if and when we are able to run a more "real world" case on a mobile device, the battery cost as well as perf will be 3-6x worse. unfortunately we dont have a way of throttling the CPU or limiting memory bandwidth yet, but i suspect that Lighthouse does expose this capability given that https://www.webpagetest.org/ offers these lower-specced devices. just keep these things in mind when saying "real world" and "fast enough".
my goal with domvm is not to surpass surplus, pico-dom, ivi or petit, it's only to ensure that domvm's perf claims align with expectations for all cases without random surprises. i believe this should be the aim of any production-quality lib.
leeoniya
on 17 Dec 2017
@leeoniya And you are doing a great job keep doing it. 👋
jorgebucaran
on 17 Dec 2017
thanks, ditto to you, good sir.
leeoniya
on 17 Dec 2017
Resolved: #499
jorgebucaran
on 1 Sep 2018
Related issues
jscriptcoder
·
4Comments
zaceno
·
3Comments
ghost
·
3Comments
joshuahiggins
·
4Comments
dmitrykurmanov
·
3Comments
Most helpful comment
(I'll repeat myself here. :smile:)
Those benchmarks should be the last thing you're looking at when choosing a framework/lib. They're highly irrelevant for most use-cases.
If you're opening a page with a 10k-row atble, I'm pretty sure you'll first wait 10 seconds to get data from the server. Who cares if rendering will be 1 or 1.2 seconds after that...