Blazor性能

Question

我想开始使用Blazor，尽管它仍然处于alpha级。

据我所知，Blazor使用WebAssembly在客户端编译C#。

我有以下问题：

这种方法比用JavaScript编译的React /JavaScript运行得更快吗？

浏览器在每次加载页面时都需要下载WebAssembly库，这是真的吗？

在互联网上，没有任何关于流行的JavaScript框架性能的比较。所以我想知道微软新框架的理论性能。

Answer 1

浏览器在每次加载页面时都需要下载WebAssembly库，这是真的吗？

不，浏览器可以缓存文件。对于Blazor应用程序来说，常见的CDN就能做到这一点。

这个系统比在JavaScript中编译的React /JavaScript更快吗？

Blazor使用WebAssembly，纸面上WebAssembly应该比任何JavaScript库都快。然而，并不是所有的浏览器都有成熟的WebAssembly解析器。因此，您可能会发现，到目前为止，浏览器将无法以最佳速度运行WebAssembly。

您可以创建一个小型Blazor应用程序，并在Firefox、Chrome或边缘中运行它。在大多数情况下，Firefox运行Blazor应用程序的速度比Chrome或Edge快得多，这意味着浏览器制造商仍然需要改进，甚至Firefox也可以改进。

如果您的应用程序需要频繁地访问DOM，那么WebAssembly / Blazor肯定比任何JavaScript库都慢，因为WebAssembly不能在不使用调用的情况下直接访问DOM (目前速度很慢)。请参考我的基准)。

在火狐上，对空方法的10,000个RegisteredFunction.InvokeUnmarshalle调用需要250 ms，而Chrome和Edge在我的PC上需要超过2400 ms。在纯JavaScript中，相同的场景需要10毫秒以下的时间。

此外，Blazor的当前实现在浏览器的塞塞引擎之上有自己的WebAssembly引擎，这意味着有两个解释器在运行Blazor项目，就像两个翻译器在一个上解释会话一样。目前，微软正在开发一个尚未发布的AOT编译器。一旦它发布，Blazor将比当前的实现快得多。

http://www.mono-project.com/news/2018/01/16/mono-static-webassembly-compilation/

我们可以有把握地假设web组装是web开发的未来，但目前我们还不能谈论Blazor的未来。从理论上讲，Blazor比任何框架都快，但是我们需要WebAssembly维护人员、浏览器开发人员、微软和社区的承诺才能使这些理论成为现实。

2018年7月10日最新情况

在WebAssembly存储库中有新的建议。

1. 允许WebAssembly直接处理DOM。https://github.com/WebAssembly/proposals/issues/8
2. WebAssembly与GC的引用类型。https://github.com/WebAssembly/reference-types/blob/master/proposals/reference-types/Overview.md

以上两项建议将为将来DOM和WebAssembly之间更快的交互铺平道路。换句话说，巴兹尔在未来会快得多。

2018年10月17日最新情况

Firefox团队能够达到JavaScript到WebAssembly调用的速度，就像JavaScript到JavaScript的方法调用一样快。到目前为止，火狐在WebAssembly支持方面远远领先于其他浏览器。

https://hacks.mozilla.org/2018/10/calls-between-javascript-and-webassembly-are-finally-fast-%F0%9F%8E%89/

Answer 2

在2021年4月，我们对一个遗留的Angular.js web应用程序以及Flutter (HTML & CanvasKit呈现器)进行了一次Blazor的测试。我们重新创建了遗留应用程序的主页(它本质上是一个包含过滤器、分页、排序等的大数据网格)。这里有几个外卖：

                                                                      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

• 网格处理-完全展示网格所需的时间(从时间线和灯塔收集的截图来判断)
• 数据传输-加载应用程序时传输的数据( DevTools中的网络选项卡，缓存已清除)
• 数据统计。-数据传输的未压缩大小(网络选项卡)
• 雷克斯。-加载应用程序时发出的请求数量(网络选项卡，缓存清除)
• 灯塔性能得分细分
• 在Windows 10上测试，Google版本89.0.4389.128 (正式构建，64位)，Intel Core i5 4460，16 64内存，有线局域网连接
• 用于构建应用程序的Relase /.NET 5，Flutter (Channel beta，2.1.0-12.2.pre)，AngularJS 1.7.7

*灯塔给出了不正确的LCP值(它计算Blazor的空白“加载.”)。页为LCP)

^Flutter的CanvasKit渲染器不允许灯塔获得LCP测量

“遗留应用比PoCs创建的要大得多，有更多的屏幕和资产会影响应用程序启动时的请求数量

Answer 3

据我所知，Blazor使用WebAssembly在客户端编译C#。

一半是真的。您可以将代码写入WebAssembly (WASM)客户端(是的，它是客户端的C# )，但也可以执行逻辑服务器端。两者都有好处。如果您使用WASM路由，所有代码都是可见的。但是，如果逻辑都是基于服务器的，它可以更快地重新复制--但是如果它是基于服务器的，那么您的代码是不可查看的。

这种方法比用JavaScript编译的React /JavaScript运行得更快吗？

不是的。我做了大量的Vue.js和Vue.js跑得更快。但我可以用Blazor更快地编写代码。而Blazor提供了一个虚拟滚动解决方案，可以使它看起来更快。在我的例子中，可用的绘图组件太慢了。我用C#和JavaScript编写了一个Blazor组件，运行得非常好。大多数情况下，我并不担心WASM代码会运行太过slow...but，而绘图需要更多的faster...and，让我拥有我的蛋糕……我只需要在JavaScript中做一些低级的工作。在过去的六个月里，Blazor的执行速度越来越快，该团队表示，当.NET 6问世时，还会有更多的事情发生。但是对于我所需要做的99%的事情来说，它已经足够快了。

浏览器在每次加载页面时都需要下载WebAssembly库，这是真的吗？

如果他们被缓存的话就不会了。即使是第一次加载，如果你有一个良好的连接，它也不会慢。它在10 MB左右。

伟大的未问问题--值得使用吗？我已经用了六个月了。

对我来说真是太棒了。C#是一种非常好的语言。有时，我想念动态添加属性，而且通常您必须手动启动重绘，但是具有可空对象检查之类的功能警告您，您没有检查代码是否会导致空引用检查--这比JavaScript要好得多。我经常觉得使用JavaScript“工具链”是很痛苦的。能够选择退出JavaScript的类库，真是太好了。