-
-
Notifications
You must be signed in to change notification settings - Fork 351
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
+ to benchmarks #271
Comments
@tomByrer This issue is hard to measure. What time slicing improves is response performance, which can make your page no longer blocked. However, the total time of page rendering is longer than that of synchronous rendering (such as Inferno). So it's unfair for fre to just measure the rendering time. Can you understand me? |
Oh wow, cheers! |
cc @ryansolid , Hey my friend, I saw your reply on twitter. My country forbids me to login twitter. I want to reply to you here. This optimization is also called Fre operates DOM in memory and paint them to the screen once at the last time. https://thoughtbot.com/blog/designing-for-ios-graphics-performance I haven't used the I generate an effect list in reverse order in the reconcile phase, and insert them into the screen in reverse order in the commit phase. This is a pure data structure and algorithm optimization. Of course, Fiber structure and two-phase traversal do provide convenience, but other singlepass frameworks (such as Vue or preact) are not completely impossible to implement this algorithm. It is worth mentioning that offscreen rendering is an optimization during the commit phase, It has little to do with concurrent mode, and time slicing is not necessary. |
To be clear I don't doubt the algorithmic/scheduling improvement. Just when people say faster than vanillajs, some clarification is needed as vanillajs(hand crafted and optimized for the specific solution) by its very nature should be the fastest. So generally I treat that claim with skepticism. |
The runtime algorithm with off-screen rendering is faster than vanillajs without off-screen optimization. Maybe it’s more appropriate to say that? |
In order to verify the results, I tested again. I was an i7 7700k windows computer, using an M6000 graphics card. The actual test of fre off-screen rendering has been faster than vanillajs, while solidjs and vanillajs are almost the same. I tested on another low configuration computer and found that the fre off-screen rendering still can be close to vanillajs , which is much better than other vdom frameworks. |
Where/what is this test? When you say offscreen rendering are you also including the cost of applying it on screen. If JS Framework is no good to show this off.. maybe like UIBench(https://github.com/localvoid/uibench)? EDIT: What is particularly good about it is it can measure the pure reconciler time or the time + paint. I usually ignore the non-paint scores but it can be useful to look at our algorithm speeds. One of the weirdest things about Solid is the non-paint times are slower comparatively to VDOM libraries, but when you add the paint in suddenly things are much closer. I'm gathering it is because the way it is measured and Solid's use of synchronous updates. Solid literally mutates the DOM immediately so even if we aren't capturing paints you would be capturing DOM mutations. Anyway I digress. This is probably a better comparison with peers. |
I went ahead and built out a benchmark: krausest/js-framework-benchmark@master...mindplay-dk:fre2-keyed Apparently it's the second time I've done that, but I forgot, haha - this one is a bit cleaner though, with a simpler Rollup build. Unfortunately, the latest published release @yisar can you publish a fresh release, please? (the I've only been able to run it by manually entering the URL after manually building - I don't have all the system dependencies set up, and the instructions in the README didn't work for me, I think they're outdated. @ryansolid presumably you have it running? Maybe you can pull my branch and try it? so we can see what's what. 🙂 |
@mindplay-dk v2.2.1 has been released. You can see the specific forces here |
@mindplay-dk As last time, this test seems unable to accurately test the framework with time slicing. Almost all frameworks use microtask. |
@mindplay-dk I played the benchmark this afternoon today, but it seems to be slower than expected. |
There's a lot of improvements to be made:
Still trying to find some core issues. To summarize, most FP methods of arrays are generally slow due to spec-related implementation. It would be better if you can implement/simplify your own array transformations just to provide faster paths. I may be wrong on some of the details I provided, feel free to rebench. |
@lxsmnsyc Thank you. You're right, but the most important thing is to implement |
Yes. That's one of the issues with Vue before up until 3.2 when they decided to introduce v-memo. If you can implement that then that would provide a lot of render skip process. |
No, the current benchmark performance metrics for fre are mainly due to the fact that the |
Very interesting take on JSX!
Would be helpful to compare performance:
https://github.com/krausest/js-framework-benchmark
I'm guessing a bit better than Inferno?
relevant discussion
The text was updated successfully, but these errors were encountered: