ChatGPT解决这个技术问题 Extra ChatGPT

Blazor performance

I would like to start using Blazor, despite the fact that it is still at the alpha level.

As I understand it, Blazor uses WebAssembly to compile C# on the client side.

And I have these questions:

Does this approach run faster than, for example, React / Vue.js, compiled in JavaScript?

Is it true that the browser will need to download the WebAssembly library every time the page loads?

On the Internet there aren't any comparisons of the performance of popular JavaScript frameworks. So I would like to know the theoretical performance of the new framework from Microsoft.

I this article @chris sainty explain it nicely. chrissainty.com/what-is-blazor-and-why-is-it-so-exciting

P
Peter Mortensen

Is it true that the browser will need to download the WebAssembly library every time the page loads?

No, browsers can cache the files. Common CDNs for Blazor applications will do the trick.

Is this system faster to work than, for example, React / Vue.js, compiled in JavaScript?

Blazor uses WebAssembly, On paper WebAssembly should be faster than any JavaScript library. However, not all browsers have a mature WebAssembly parser yet. So you might find that browsers will not run WebAssembly in an optimal speed as of now.

You can create a small Blazor application and run it in Firefox, Chrome or Edge. In most cases, Firefox runs Blazor applications much faster than Chrome or Edge, which implies that browser makers still need to improve, and even Firefox can improve.

If your application needs to access the DOM frequently, then definitely WebAssembly / Blazor will be slower compared to any JavaScript libraries since WebAssembly can’t directly access the DOM without using Invokes (which is slow at the moment. Please refer my Blazor benchmark below).

On Firefox, 10,000 RegisteredFunction.InvokeUnmarshalle calls to empty methods takes 250 ms while Chrome and Edge need more than 2400 ms in my PC. In pure JavaScript it takes below 10 milliseconds for the same scenario.

Additionally, the current implementation of Blazor has its own MSIL engine on top of the browser's WebAssembly engine, which means there are two interpreters working to run a Blazor project, like two translators interpreting a conversation instead on one. Currently Microsoft is working on an AOT compiler, which is not yet released. Once it's released, Blazor will be much faster than the current implementation.

Mono and WebAssembly - Updates on Static Compilation

We can safely assume that the web assembly is the future of web development, but at the moment we can’t say anything about Blazor’s future. On paper, Blazor can be faster than any framework out there, however we need commitment from WebAssembly maintainers, browser developers, Microsoft and the communities to make the theories practical.

Update 10th July 2018

There are new proposals in the WebAssembly repositories.

Allowing WebAssembly to handle DOM directly. Interface types #8 Reference Types for WebAssembly with GC. Reference Types for WebAssembly

The above two proposals will pave the path to much faster interaction between the DOM and WebAssembly in the future. In other words, Blazor will be much faster in the future.

Update 17 October 2018

The Firefox team was able to reach a JavaScript-to-WebAssembly call as fast as JavaScript-to-JavaScript method calls. As of now Firefox is far ahead of any other browsers when it comes to WebAssembly support.

Calls between JavaScript and WebAssembly are finally fast


My understanding is one reason that React and now Angular and other frameworks are very fast is the virtual DOM concept, comparing to the actual DOM, and only applying the differences. Is that something that Blazor does or is planned to do in the future?
@Cleverguy25 Angular does NOT use a virtual DOM...React does, which is why react will give better performance on large apps
@Cleverguy25 Blazor use virtual DOM as like as React that might make it quite fast. Angular had a try to use virtual Dom but as I know it has been withdraw.
Blazor has a virtual DOM in order to only apply delta updates to html. It also interprets code, currently no wasm compilation.
AOT complier pushed to Q1 of 2021.
M
Maxim Saplin

On April 2021 we did a trial of Blazor WASM against a legacy Angular.js web app, as well as against Flutter Web (HTML & CanvasKit renderers). We've recreated the main page of the legacy app (which is essentially a big data grid with filters, pagination, sorting etc.). Here're a few takeaways:

                                                                      Lighthouse perf. Scores
                   Grid Displ.  Data transf.  Data uncomp.  Reqs.  FCP   SI   LCP  TTI  TBT  CLS
Blazor*            2.2s         4.7MB         13.7MB        99     0.5s  1.6s 0.5s 2.1s 1.3s 0.01 
Flutter HTML       1.7s         2.1MB          3.7MB        15     1.9s  2.5s 2.2s 2.3  0.2s 0
Flutter CanvasKit^ 2.8s         4.7MB         10.5MB        17     1.0s  2.2s -/-  2.2s 1s   0   
AngularJS`         1.9s         2.0MB          5.7MB        294    2.1s  2.2s 2.6s 2.6s 0.1s 0

Grid Displ. - time it took to completely display the gird (judging by the timeline and screenshots gathered by Lighthouse)

Data transf. - data transfered when loading the app (Network tab in DevTools, caches cleared)

Data uncomp. - uncompressed size of data transfered (Network tab)

Reqs. - number of requests issued while loading the app (Network tab, caches cleared)

Lighthouse Performance score breakdown

Tested on Windows 10, Google Chrome Version 89.0.4389.128 (Official Build, 64-bit), Intel Core i5 4460, 16GB RAM, wired LAN connection

Relase configs used to build apps, Blazor WASM/.NET 5, Flutter (Channel beta, 2.1.0-12.2.pre), AngularJS 1.7.7

*Lighthouse gives incorrect LCP value (it counts Blazor's blank 'Loading...' page as LCP)

^Flutter's CanvasKit renderer doesn't allow Lighthouse to get LCP measurement

`Legacy app is much bigger then PoCs created, there're many more screens and assets which affect the number of requests upon app launch


did you use Blazor with gRPC or the normal Http? I think you could get better results with gRPC implemented.
Blazor, as well as Flutter clients, used gRPC Web.
Steve Sanderson wrote in his Blog, that Blazor WASM is using JSON-over-HTTP by default. So you have to implement gRPC explicit. blog.stevensanderson.com/2020/01/15/…
Pardon me, but you seem to be confusing notions and looks like you didn't have experience with gRPC. There's no explicit or implicit implementation of gRPC, web browser (and thus any SPA such as Blazor) can use gRPC only via HTTP/HTTPs via a proxy called gRPC Web. A side note, using gRPC has nothing to do with the above tests, gRPC could give -5KB difference on 30-40KB data set fetched from the server to display the grid, time diff will be inivisible in the bulk of time spent in scripting
I see your point... The above figures show total traffic when loading the app for the first time - this includes HTML, CSS, JS, WASM modules, DLLs etc. The amount of gRPC traffic at first load is about 30KB (data for the grid in the page) which is negligible when the totals are in range of 5-14 MBs
P
Peter Mortensen

As I understand it, Blazor uses WebAssembly to compile C# on the client side.

Half true. You can write your code to WebAssembly (WASM) client side (yes, it is C# on the client side), but you can also execute the logic server side. Both have benefits. All your code is visible if you go the WASM route. But it can rerender faster than if the logic is all server based -- but if it's server based your code isn't viewable.

Does this approach run faster than, for example, React / Vue.js, compiled in JavaScript?

No. I've done a ton of Vue.js and Vue.js runs faster. But I can write code a lot faster using Blazor. And Blazor offers a virtual scrolling solution that can make it appear faster. In my case the available plotting components were too slow. I wrote a Blazor component using C# and JavaScript that worked very well. Most of the time I don't worry about the WASM code running too slow...but the plotting needed to be much faster...and Blazor let me have my cake...I just had to do some low level work in JavaScript. Blazor execution has gotten faster over the last six months and the team says there is more to come when .NET 6 comes out. But it's more than fast enough for 99% of what I've ever need to do.

Is it true that the browser will need to download the WebAssembly library every time the page loads?

Not if they are cached. And even the first time they load, it isn't slow if you have a decent connection. It is on the order of 10 MB.

The great unasked question -- is it worth using? I've been using it for about six months.

For me it has been great. C# is a very good language. Sometimes I miss adding a property dynamically and often you have to manually initiate a redraw, but with features like nullable object checks warning you that you didn't check if your code could cause a null reference check -- it is much better than JavaScript. I often felt it was painful to work with the JavaScript "toolchain". It is so nice to be able to opt out of the library thrash of JavaScript.


G
Gilbert

The ASP.NET Core roadmap for .NET 6 can be found on github here. You will find that Blazor has by far the most tasks.

Note that the list indicates those items the ASP.NET team will be focusing on meaning that they are putting alot of their emphasis on improving Blazor.

This issue represents the list of major investments our team will focus on during .NET 6 timeframe. The items on this list are only major areas of investments, and do not include all the features and bugfixes we will be tackling during this time.

Below are some of the tasks they have been working on:

Tasks completed:

AOT Compilation. Compile everything to WebAssembly Improve SVG support in Blazor. Top-level issue for SVG support in Blazor Support byte-array transfer in JS Interop.

Tasks in progress

Hot reload for Blazor. Build performance optimization Pause and resume Blazor applications. Target and deploy to desktop platforms. Remove size limitations imposed by SignalR message size. Drag & Drop. Provide events that users can subscribe to during drag and drop


And SVG support is truly phenomenal now. Inline SVG could almost completely replace HTML for many tasks.