资讯专栏INFORMATION COLUMN

JavaScript与WebAssembly进行比较

IntMain / 2658人阅读

摘要:目前,是围绕和用例设计的。多线程在单个线程上运行。目前不支持多线程。

本文由云+社区发表

作者:QQ音乐前端团队

在识别和描述核心元素的过程中,我们分享了构建SessionStack时使用的一些经验法则,这是一个轻量级但健壮且高性能的JavaScript应用程序,以帮助用户实时查看和重现其Web应用程序的缺陷。

这次我们来分析WebAssembly的工作原理,以及在如下几个方面和JavaScript进行比较:加载时间,执行速度,垃圾回收,内存使用情况,平台API访问,调试,多线程和可移植性。

WebAssembly的功能

WebAssembly(又名wasm)是一种高效的,低级别的编程语言。 它让我们能够使用JavaScript以外的语言(例如C,C ++,Rust或其他)编写程序,然后将其编译成WebAssembly,进而生成一个加载和执行速度非常快的Web应用程序。

加载时间

为了加载JavaScript,浏览器必须加载所有.js文本文件。 WebAssembly在浏览器中加载速度更快,因为只有已编译的wasm文件才通过互联网传输。并且wasm是一种非常简洁的二进制格式的低级汇编语言,文件更小。

执行

目前Wasm 比本地代码执行速度慢20%。这倒是一个令人吃惊的结果,不过,这是一种编译到沙盒环境中的格式并且在很多约束条件下运行,以确保它没有安全漏洞或者很难攻防这个漏洞。与真实的本地代码相比,其实速度下降很小。但是,未来它会更快。

更好的是,它与浏览器无关 - 所有主要引擎都增加了对WebAssembly的支持,并且现在提供类似的执行时间。我们来看看简单看看V8中发生了什么:

V8 Approach: lazy compilation

在左边,我们有一些JavaScript源代码,包含JavaScript函数。它首先需要进行分析,以便将所有字符串转换为标记并生成抽象语法树(AST)。AST是JavaScript程序逻辑的内存表示。一旦生成这种表示,V8直接转到机器码。一般来说,只需要遍历树,生成机器代码,便生成了编译好的函数。从这个过程可以看出,这个阶段并没有编译速度的优势。 现在,我们来看看V8管道在下一阶段的功能:

V8管道设计

这次我们有TurboFan,V8的优化编译器之一。当您的JavaScript应用程序正在运行时,很多代码在V8中运行。TurboFan可以监控运行缓慢的内容,是否存在瓶颈和热点以优化它们。它将它们推送到后端,这是一个优化的JIT,它可以优化那些非常耗cpu的代码。 虽然它解决了上述问题,但是新的问题在于:分析代码并决定优化哪些内容的过程也会消耗CPU。这反过来又意味着更高的电池消耗,特别是在移动设备上。 然而,wasm不一样在于,它会被插入工作流程中,如下所示:

内存模型

WebAssembly可信和不可信状态 例如,编译成WebAssembly的C ++程序的内存是连续的内存块,其中没有“漏洞”。有助于提高安全性的wasm的特性之一是执行堆栈与线性内存分离的概念。在一个C ++程序中,你有一个内存堆,你从堆的底部分配,然后从堆顶增涨堆大小。这便产生一个很多恶意软件利用的漏洞:用一个指针就可以在堆栈内存中查找数据从而更改变量,而这些数据本是你不应该访问到的。

WebAssembly采用完全不同的模型。执行堆栈与WebAssembly程序本身是分开的,因此您无法在其中修改并更改变量等内容。而且,这些函数使用整数偏移而不是指针。函数指向一个间接函数表。然后这些直接计算的数字跳转到模块内部的函数中。它是以这种方式构建的,以便您可以同时加载多个wasm模块,形成多个索引列表,并且一切正常。 有关JavaScript中内存模型和管理的更多信息,可以查看关于该主题的非常详细的帖子。

垃圾回收

您已经知道JavaScript的内存管理是使用垃圾回收器处理的。

WebAssembly的情况有点不同。它支持手动管理内存的语言。您可以自定义在WASM上的垃圾回收模块,但是这个比较复杂。

目前,WebAssembly是围绕C ++和RUST用例设计的。由于wasm是非常低级的,因此只有汇编语言上一步的编程语言才易于编译。C可以使用普通的malloc,C ++可以使用智能指针,Rust使用完全不同的模式(完全不同的主题)。这些语言不使用GC,因此它们不需要所有复杂的运行时内容来跟踪内存。WebAssembly对他们来说是天作之合。

另外,这些语言并不是100%设计用于调用复杂的JavaScript事物,如DOM。在C ++中编写整个HTML应用程序是没有意义的,因为C ++不是为它设计的。在大多数情况下,当工程师编写C ++或Rust时,他们的目标是WebGL或高度优化的库(例如重数学计算)。

但是,将来WebAssembly将支持不附带GC的语言。

平台API访问

取决于执行JavaScript的运行时,可以通过你的JavaScript应用程序来访问平台相关的API。例如,如果您在浏览器中运行JavaScript,则您有一组Web APIs,Web应用程序可以调用它来控制Web浏览器/设备功能并访问DOM, CSSOM, WebGL, IndexedDB, Web Audio API等。

然而,WebAssembly模块无法访问任何平台API。一切都是由JavaScript调用的。如果您想访问WebAssembly模块中的某些平台特定的API,则必须通过JavaScript调用它。

例如,如果你想console.log,你必须通过JavaScript来调用它,而不是你的C ++代码。这些JavaScript调用的成本有所降低。

这并不总是如此。该规范将在未来为平台API提供wasm,并且您将能够在没有JavaScript的情况下发布您的应用程序。

Source maps

当您精简JavaScript源代码时,您需要一种正确方式调试它。这就需要Source Maps。基本上, Source Maps 是一种将组合/缩小文件映射回未建立状态的方法。当您为生产而构建时,同时缩小和组合您的JavaScript文件,您将生成一个包含原始文件信息的源映射。当您在生成的JavaScript中查询某一行和列号时,可以在返回原始位置的源地图中执行查找。

WebAssembly目前不支持source maps,因为没有规范,但最终会支持(可能很快)。 当您在C ++代码中设置断点时,您将看到C ++代码而不是WebAssembly。

多线程

JavaScript在单个线程上运行。有很多方法可以利用Event Loop并利用异步编程。

JavaScript也使用Web Workers,但他们有一个非常具体的用例 - 基本上,可能阻塞主UI线程的任何CPU密集计算都可以进入到Web Worker中来提高性能。但是,Web Workers无法访问DOM。

WebAssembly目前不支持多线程。但是,这可能是未来的事情。Wasm将更接近本地线程(例如C ++样式线程)。拥有“真实”的线程将在浏览器中创造出许多新的机会。当然,这将打开更多滥用可能性的大门。

可移植性

如今,JavaScript几乎可以在任何地方运行,从浏览器到服务器端甚至嵌入式系统。

WebAssembly被设计为安全和便携。就像JavaScript一样。它将运行在支持主机的每个环境中(例如每个浏览器)。就像当年的Java的Applets,WebAssembly有相同的可移植性的愿景。

哪些场景更合适使用WA

在WebAssembly的第一个版本中,主要关注CPU占用大的计算(例如处理数学)。想到的最主流的用途是游戏 - 那里有大量的像素操作。您可以使用您习惯的OpenGL在C ++ / Rust中编写您的应用程序,并将其编译为wasm。它会在浏览器中运行。 看看这个(在Firefox中运行)

http://s3.amazonaws.com/mozil...。

这是 Unreal engine.。

另一种使用WebAssembly(性能方面)可能有意义的情况是实现一些库,这是一个CPU密集型工作。例如,一些图像处理。

如前所述,由于大多数处理步骤都是在编译期间提前完成的,因此wasm可以减少移动设备上的电池消耗(取决于引擎)。

将来,即使您实际上没有编写编译代码,您也可以使用WASM二进制文件。您可以在NPM中找到开始使用此方法的项目。

对于DOM操作和沉重的平台API使用,使用JavaScript确实很有意义,因为它不会增加额外的开销,并且具有本地提供的API。

在SessionStack中,我们不断增强JavaScript的性能,以编写高度优化且高效的代码。我们的解决方案需要提供超快的性能,因为我们不能阻碍客户应用的性能。将SessionStack集成到生产Web应用程序或网站后,它会开始记录所有内容:所有DOM更改,用户交互,JavaScript异常,堆栈跟踪,失败的网络请求和调试数据。所有这些都在您的生产环境中进行,而不会影响产品的任何UX和性能。我们需要大量优化我们的代码并尽可能使其异步。

不仅仅是库文件,当在SessionStack中重放用户回话时,我们会渲染用户浏览器中发生的所有事件,并且我们必须重构整个状态,允许您在会话时间线中来回跳转。因为没有更好的选择,为了做到这一点,我们大量使用了JavaScript提供的异步机会。

借助WebAssembly,我们将能够将一些最繁重的处理和渲染转换为更适合作业的语言,并将数据收集和DOM操作保留为JavaScript。

如果你想尝试下SessionStack,你可以免费开始。有一个免费的计划),每月提供1000个会话。

参考:

https://www.youtube.com/watch...

https://www.youtube.com/watch...

此文已由腾讯云+社区在各渠道发布

获取更多新鲜技术干货,可以关注我们腾讯云技术社区-云加社区官方号及知乎机构号

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/101804.html

相关文章

  • JavaScriptWebAssembly进行比较

    摘要:目前,是围绕和用例设计的。多线程在单个线程上运行。目前不支持多线程。 本文由云+社区发表作者:QQ音乐前端团队 在识别和描述核心元素的过程中,我们分享了构建SessionStack时使用的一些经验法则,这是一个轻量级但健壮且高性能的JavaScript应用程序,以帮助用户实时查看和重现其Web应用程序的缺陷。 这次我们来分析WebAssembly的工作原理,以及在如下几个方面和Ja...

    617035918 评论0 收藏0
  • 前端每周清单半年盘点之 WebAssembly

    摘要:前端每周清单专注前端领域内容,以对外文资料的搜集为主,帮助开发者了解一周前端热点分为新闻热点开发教程工程实践深度阅读开源项目巅峰人生等栏目。利用降低三倍加载速度自推出之后,很多开发者都开始尝试在小型项目中实践,不过尚缺大型真实案例比较。 前端每周清单专注前端领域内容,以对外文资料的搜集为主,帮助开发者了解一周前端热点;分为新闻热点、开发教程、工程实践、深度阅读、开源项目、巅峰人生等栏目...

    Alan 评论0 收藏0
  • WebAssembly 系列(五)为什么 WebAssembly 更快?

    摘要:图表中的比例并不代表真实情况下的确切比例情况。解析当到达浏览器时,源代码就被解析成了抽象语法树。解析过后抽象语法树就变成了中间代码叫做字节码,提供给引擎编译。目前为止,不支持垃圾回收。这就是为什么在大多数情况下,同一个任务比表现更好的原因。 作者:Lin Clark 编译:胡子大哈 翻译原文:http://huziketang.com/blog/posts/detail?postId...

    刘德刚 评论0 收藏0
  • WebAssembly 那些事儿

    摘要:的目标是对高级程序中间表示的适当低级抽象,即代码旨在由编译器生成而不是由人来写。表示把源代码变成解释器可以运行的代码所花的时间表示基线编译器和优化编 WebAssembly 那些事儿 什么是 WebAssembly? WebAssembly 是除 JavaScript 以外,另一种可以在网页中运行的编程语言,并且相比之下在某些功能和性能问题上更具优势,过去我们想在浏览器中运行代码来对网...

    邱勇 评论0 收藏0
  • WebAssembly 系列(六)WebAssembly 的现在未来

    摘要:目前正在开发两个编译器系统。这就意味着有很多功能还在襁褓之中,没有经过彻底思考以及实际验证。这些特性叫做未来特性。实现这一功能将会使用中的,而这一功能的实现将会提高程序执行的效率。目前浏览器在逐渐支持用标记来加载模块。 作者:Lin Clark 编译:胡子大哈 翻译原文:http://huziketang.com/blog/posts/detail?postId=58ce7fd3a6...

    mcterry 评论0 收藏0

发表评论

0条评论

最新活动
阅读需要支付1元查看
<