或许你并不需要 Rust 和 WASM 来提升 JS 的执行效率 — 第一部分 #3965
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
或许你并不需要 Rust 和 WASM 来提升 JS 的执行效率 — 第一部分
|
@leviding 校对认领 |
|
@geniusq1981 好的呢 🍺 |
geniusq1981
reviewed
Jun 9, 2018
|
|
||
| Few weeks ago I noticed a blog post [“Oxidizing Source Maps with Rust and WebAssembly”](https://hacks.mozilla.org/2018/01/oxidizing-source-maps-with-rust-and-webassembly/) making rounds on Twitter - talking about performance benefits of replacing plain JavaScript in the core of `source-map` library with a Rust version compiled to WebAssembly. | ||
| 几个星期前，我在 Twitter 上看到一篇名为 [“Oxidizing Source Maps with Rust and WebAssembly”](https://hacks.mozilla.org/2018/01/oxidizing-source-maps-with-rust-and-webassembly/) 的推文，其内容主要是讨论用 Rust 编写的 WebAssembly 替换 `source-map` 核心中的纯 JavaScript 部分带来的性能优势。 |
There was a problem hiding this comment.
其内容主要是讨论用 Rust 编写的 WebAssembly 替换 source-map 核心中的纯 JavaScript 部分带来的性能优势。=>其内容主要是讨论用 Rust 编写的 WebAssembly 替换 source-map 库中纯 JavaScript 编写的核心代码所带来的性能优势。
|
|
||
| So I checked out the library from GitHub and departed on a small performance investigation, which I am documenting here almost verbatim. | ||
| 于是我从 GitHub 检出了这个库，然后逐字逐句的记录了这次小型性能调查。 |
|
|
||
| For my investigations I was using an _almost_ default x64.release build of the V8 at commit [69abb960c97606df99408e6869d66e014aa0fb51](https://chromium.googlesource.com/v8/v8/+/69abb960c97606df99408e6869d66e014aa0fb51) from January 20th. My only departure from the default configuration is that I enable disassembler via GN flags to be able to dive down to generated machine code if needed. | ||
| 对于我的调查，当时使用的是**近乎**默认配置的 x64.release 的 V8，V8 版本对应着 1 月 20 日的提交历史 commit [69abb960c97606df99408e6869d66e014aa0fb51](https://chromium.googlesource.com/v8/v8/+/69abb960c97606df99408e6869d66e014aa0fb51)。为了能够根据需要深入到生成的机器码，我通过 GN 标志启用了反汇编程序，这是我唯一偏离默认配置的地方。 |
There was a problem hiding this comment.
对于我的调查，当时使用的是近乎默认配置的 x64.release 的 V8，V8 版本 => 对于我的研究，当时使用的是近乎默认配置的 x64 V8 的发布版本
| @@ -106,11 +106,11 @@ Overhead Symbol | |||
| 0.56% v8::internal::IncrementalMarking::RecordWriteSlow | |||
| ``` | |||
|
|
|||
| Indeed, just like the [“Oxidizing Source Maps …”](https://hacks.mozilla.org/2018/01/oxidizing-source-maps-with-rust-and-webassembly/) post has stated the benchmark is rather heavy on sort: `doQuickSort` appears at the top of the profile and also several times down the list (which means that it was optimized/deoptimized few times). | |||
| 事实上, 就像 [“Oxidizing Source Maps …”](https://hacks.mozilla.org/2018/01/oxidizing-source-maps-with-rust-and-webassembly/) 那篇博文说的那样，基准测试在排序上相当重：`doQuickSort` 出现在配置文件的顶部，并且在列表中还多次出现（这意味着它已被优化/去优化了几次）。 | |||
There was a problem hiding this comment.
基准测试在排序上相当重： => 基准测试相当侧重于排序上：
| @@ -149,9 +149,9 @@ function doQuickSort(ary, comparator, p, r) { | |||
| } | |||
| ``` | |||
|
|
|||
| Grepping through library sources reveals that outside of tests `quickSort` is only ever called with these two functions. | |||
| 通过梳理源代码发现除了测试之外，`quickSort` 只有用这两个函数才能调用。 | |||
There was a problem hiding this comment.
quickSort 只有用这两个函数才能调用。=> quickSort 只被这两个函数调用过。
|
|
||
| In V8 we seem to be spending roughly as much time parsing mappings as sorting them. In SpiderMonkey parsing is considerably faster - while sorting is slower. This prompted me to start looking at the parsing code. | ||
| 在 V8 中，我们似乎花费大量的时间来解析映射，以便对它们进行排序。在 SpiderMonkey 中，解析映射速度更快，反而是排序较慢。这促使我开始查看解析代码。 |
There was a problem hiding this comment.
在 V8 中，我们似乎花费大量的时间来解析映射，以便对它们进行排序 =>在 V8 中，我们花费几乎和排序差不多的时间来进行解析映射。
|
|
||
| **On one hand is pure parsing:** | ||
| **一方面是纯粹的解析：** |
|
|
||
| **On the other hand caching:** | ||
| **另一方面缓存：** |
|
|
||
| Parsing segment looks at each character of a segment once. For each character it performs few comparisons and arithmetic operations to convert a base64 character into an integer value it represents. Then it performs few bitwise operations to incorporate this integer value into a larger integer value. Then it stores decoded value into an array and moves to the next part of the segment. Segments are limited to 5 elements. | ||
| 解析分段只查看一个分段的每个字符。对于每个字符，它执行少量比较和算术运算，将 base64 字符转换为它所表示的整数值。然后它执行几个按位操作来将此整数值并入较大的整数值。然后它将解码值存储到一个数组中并移动到该段的下一部分。细分受限于 5 个元素。 |
There was a problem hiding this comment.
细分受限于 5 个元素。 => 分段不得多于5个
|
@shery15 @leviding 校对完成 |
|
感谢校对，辛苦了！ |
leviding
approved these changes
Jun 16, 2018
|
@shery15 格式存在问题，看下我的 commit 记录，对照译者教程，下次避免这些问题。 @geniusq1981 指出格式问题也是校对者的职责之一，译者教程中都有说明，注意一下。 |
|
@shery15 已经 merge 啦~ 快快麻溜发布到掘金然后给我发下链接，方便及时添加积分哟。 掘金翻译计划有自己的知乎专栏，你也可以投稿哈，推荐使用一个好用的插件。 |
|
格式问题我会再小心点，尽可能提高翻译质量。 |
shery
deleted the
translation/maybe-you-dont-need-rust-to-speed-up-your-js-1.md
branch
|
细节要求有点多，搞过之后就知道了 👍 辛苦啦 |
Open
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
或许你并不需要 Rust 和 WASM 来提升 JS 的执行效率 — 第一部分
译文翻译完成，resolve #3930