logo标签列表

Blazor性能

asp.netperformanceblazorwebassembly
108

尽管Blazor仍处于alpha版本，但我希望开始使用它。

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

我的问题如下：

这种方法是否比例如React / Vue.js等JavaScript编译更快？

浏览器每次加载页面时是否需要下载WebAssembly库？

因为互联网上没有流行JavaScript框架性能的比较，所以我想了解微软新框架的理论性能。

在这篇文章中，@chris sainty很好地解释了它。https://chrissainty.com/what-is-blazor-and-why-is-it-so-exciting/ - Majedur
许多需要评论的事情：尽管Blazor仍处于alpha级别，但我想开始使用它。 Blazor现在已经达到了生产级别。这种方法是否比编译为JavaScript的React / Vue.js运行得更快？ 是的，远远如此，WebAssembly是一种低级语言，实际上比任何js框架都要快。浏览器是否每次加载页面时都需要下载WebAssembly库？ 不需要。有两种类型的Blazor应用程序，如果您想完全在客户端加载应用程序（无服务器），则可以使用WebAssembly方法，其他 - hesolar
5个回答
171

浏览器每次加载页面时都需要下载WebAssembly库吗？

不需要，浏览器可以缓存文件。通常为Blazor应用程序提供的CDNs就可以解决这个问题。

相比于JavaScript编译的React/Vue.js等库，这个系统工作速度更快吗？

Blazor使用WebAssembly，在理论上，WebAssembly应该比任何JavaScript库更快。然而，并非所有浏览器都有成熟的WebAssembly解析器。因此，您可能会发现，目前一些浏览器无法以最优速度运行WebAssembly。

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

如果您的应用程序需要频繁访问DOM，那么与任何JavaScript库相比，WebAssembly/Blazor肯定会更慢，因为WebAssembly不能直接访问DOM，必须使用调用（目前速度较慢，请参见下面的Blazor基准测试）。

在Firefox上，对于空方法的10,000个RegisteredFunction.InvokeUnmarshalle调用只需要250毫秒，而Chrome和Edge在我的电脑上需要超过2400毫秒。在纯JavaScript中，相同的场景只需要不到10毫秒。

此外，Blazor的当前实现在浏览器的WebAssembly引擎之上有自己的MSIL引擎，这意味着有两个解释器正在运行Blazor项目，就像两个翻译员相互解释一样。目前，Microsoft正在开发一个AOT编译器，但尚未发布。一旦发布，Blazor将比当前的实现更快。

Mono and WebAssembly - Updates on Static Compilation

我们可以安全地假设WebAssembly是Web开发的未来，但目前我们无法确定Blazor的未来。从理论上讲，Blazor可能比任何其他框架都要快，但我们需要WebAssembly维护者、浏览器开发人员、Microsoft和社区的承诺来使这些理论得以实现。

更新时间：2018年7月10日

WebAssembly仓库中有新的提案。

  1. 允许WebAssembly直接处理DOM。

    接口类型 #8

  2. 带垃圾回收的WebAssembly参考类型。WebAssembly参考类型

以上两个提案将为将来DOM和WebAssembly之间更快速的交互铺平道路。换句话说，Blazor在将来将会更快。

更新于2018年10月17日

火狐团队成功实现了JavaScript到WebAssembly的调用速度与JavaScript到JavaScript方法调用一样快。目前火狐在支持WebAssembly方面遥遥领先于其他任何浏览器。

JavaScript和WebAssembly之间的调用终于变得很快了

3
我理解的是React和现在的Angular以及其他框架之所以很快，是因为虚拟DOM的概念，与实际DOM相比，只应用差异。这是Blazor当前或将来计划实现的吗？ - Cleverguy25
2
@Cleverguy25 Angular不使用虚拟DOM...React使用虚拟DOM，这就是为什么在大型应用程序上React会提供更好的性能。 - MattE
2
@Cleverguy25 Blazor 使用虚拟 DOM，就像 React 一样，这可能使它非常快。Angular 曾尝试使用虚拟 DOM，但据我所知已被撤回。 - nzrytmn
4
Blazor拥有虚拟DOM，以便只对HTML应用增量更新。它还会解释代码，目前不支持WASM编译。 - Peter Morris
3
AOT编译器推迟至2021年第一季度。 - Rohan Bojja
显示剩余2条评论
16

2021年4月，我们针对一款传统的Angular.js Web应用程序以及Flutter Web（HTML和CanvasKit渲染器）进行了Blazor WASM试验。 我们重新创建了传统应用程序的主页面（本质上是一个带有筛选、分页、排序等功能的大型数据表格）。以下是一些要点：

                                                                      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
  • 网格渲染时间 - 完全显示网格所需的时间（根据Lighthouse收集的时间线和截图判断）
  • 数据传输量 - 加载应用程序时传输的数据量（DevTools中的网络选项卡，已清除缓存）
  • 未压缩数据 - 传输的未压缩数据大小（网络选项卡）
  • 请求数 - 加载应用程序时发出的请求数量（网络选项卡，已清除缓存）
  • Lighthouse性能得分详细信息
  • 测试环境：Windows 10，Google Chrome版本89.0.4389.128（官方构建版，64位），Intel Core i5 4460，16GB RAM，有线局域网连接
  • 发布配置用于构建应用程序，Blazor WASM/.NET 5、Flutter（beta频道，2.1.0-12.2.pre）、AngularJS 1.7.7

*Lighthouse给出的LCP值不正确（它将Blazor的空白“正在加载...”页面视为LCP）

^Flutter的CanvasKit渲染器不允许Lighthouse进行LCP测量

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

你使用了Blazor和gRPC还是普通的Http？我认为你可以通过实现gRPC获得更好的结果。 - JoeGER94
Steve Sanderson在他的博客中写道，Blazor WASM默认使用JSON-over-HTTP。因此，您必须显式地实现gRPC。 https://blog.stevensanderson.com/2020/01/15/2020-01-15-grpc-web-in-blazor-webassembly/ - JoeGER94
2
我理解你的观点... 上述数据显示了首次加载应用程序时的总流量 - 包括HTML、CSS、JS、WASM模块、DLL等。首次加载时gRPC流量的数量约为30KB（页面中网格的数据），相对于5-14 MB的总量来说可以忽略不计。 - Maxim Saplin
是的，谢谢大家的讨论。非常有启发性。 - Gilbert
我想在这个列表中看到一个纯粹使用C语言编写的基本Web Assembly。 - sanepete
显示剩余3条评论
10
据我了解，Blazor使用WebAssembly在客户端编译C#代码。
有一半是正确的。您可以将代码编写为WebAssembly（WASM）客户端端（是的，它是客户端上的C#），但也可以在服务器端执行逻辑。 两者都有好处。 如果选择WASM路线，则所有代码都可见。 但是，如果逻辑全部基于服务器，则可以重新渲染得更快 - 但如果基于服务器，则您的代码无法查看。
这种方法是否比编译为JavaScript的React / Vue.js运行得更快？
我已经使用过很多Vue.js，Vue.js运行速度更快。但是，使用Blazor编写代码可以更快。Blazor提供了一个虚拟滚动解决方案，可以使其看起来更快。在我的情况下，可用的绘图组件太慢了。我使用C#和JavaScript编写了一个Blazor组件，效果非常好。大多数时候，我不担心WASM代码运行得太慢...但是绘图需要更快...而Blazor让我得到了想要的结果...我只需要在JavaScript中做一些低级工作。过去六个月里，Blazor的执行速度已经变得更快了，团队表示.NET 6发布后还会有更多改进。但对于我所需做的99%的工作来说，它已经足够快了。
“浏览器每次加载页面都需要下载WebAssembly库”这种说法不准确，如果缓存了就不需要。即使是第一次加载，如果您的连接良好，也不会很慢。它的大小约为10 MB。

一个重要的问题——它值得使用吗？我已经使用它大约六个月了。

对我来说，它非常好用。C#是一种很好的语言。有时候我会想念动态添加属性的功能，而且你经常需要手动启动重绘，但是有了像可空对象检查这样的特性，它会警告你没有检查你的代码是否可能导致空引用检查——它比JavaScript好多了。我经常觉得使用JavaScript "工具链"很痛苦。能够选择退出JavaScript库的混乱真是太好了。

7
ASP.NET Core的路线图可以在GitHub上找到，链接在这里。您会发现Blazor拥有迄今为止最多的任务。
请注意，该列表指出了ASP.NET团队将会关注的项目，这意味着他们正在非常重视改进Blazor。
以下是他们正在进行的一些任务:
已完成的任务:
1. AOT编译。将所有内容编译为WebAssembly。 2. 改进Blazor中的SVG支持。SVG支持在Blazor中的顶级问题。 3. 在JS互操作性中支持字节数组传输。
正在进行的任务:
1. Blazor的热重新加载。构建性能优化。 2. 暂停和恢复Blazor应用程序。 3. 面向桌面平台的目标和部署。 4. 移除SignalR消息大小所施加的大小限制。 5. 拖放。提供用户在拖放期间可以订阅的事件。
3
现在SVG的支持非常出色。对于许多任务来说，嵌入式SVG几乎可以完全替代HTML。 - Bennyboy1973
1

基于：.net 7（2023 更新）

Blazor 网站现在更加成熟，当使用适当的 brotli 压缩和裁剪时速度更快。理论上，通过利用 WebAssembly 的性能优势，Blazor 可以在浏览器中实现类似本地的性能，这使其成为高性能应用程序的不错选择，但这只有在 wasm 直接访问 DOM 时才能看到。虽然还没有达到标准，但能够为前端 Web 应用编写 C# 代码是一种魔法。

如果您有兴趣看到它的实际效果，请务必查看我们自己的项目 PhotosNepal.com - 这是一个完全基于 Blazor 构建的库存图像网站。我们对结果感到满意，但还有一些需要改进的地方。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接