胜者是 Stream：NodeJS 读取大数据集合几种方法的性能比较

TODO1/streams-for-the-win-a-performance-comparison-of-nodejs-methods-for-reading-large-datasets-pt-2.md

@@ -3,15 +3,15 @@
 > * 译文出自：[掘金翻译计划](https://github.com/xitu/gold-miner)
 > * 本文永久链接：[https://github.com/xitu/gold-miner/blob/master/TODO1/streams-for-the-win-a-performance-comparison-of-nodejs-methods-for-reading-large-datasets-pt-2.md](https://github.com/xitu/gold-miner/blob/master/TODO1/streams-for-the-win-a-performance-comparison-of-nodejs-methods-for-reading-large-datasets-pt-2.md)
 > * 译者：[lucasleliane](https://github.com/LucaslEliane)
-> * 校对者：
+> * 校对者：[Ultrasteve](https://github.com/Ultrasteve)，[xilihuasi](https://github.com/xilihuasi)
 
 # 胜者是 Stream：NodeJS 读取大数据集合几种方法的性能比较
 
 ## readFile()、createReadStream() 以及事件流如何相互比较
 
 ![](https://cdn-images-1.medium.com/max/2000/1*fsseXIPGEhwmg6kfgXyIjA.jpeg)
 
-如果你最近都在阅读我的文章，你应该会看到我几周前发布的一篇[博客](https://itnext.io/using-node-js-to-read-really-really-large-files-pt-1-d2057fe76b33)，这篇博客讨论了使用 Node.js 来读取大型数据集的各种方法。
+如果你一直在关注我的文章，你应该会看到我几周前发布的一篇[博客](https://juejin.im/post/5d4b99eb5188257bc15d299f)，这篇博客讨论了使用 Node.js 来读取大型数据集的各种方法。
 
 令我惊讶的是，这篇博客受到了很多读者的喜爱 - 这个主题（对于我来说）似乎在很多其他的帖子、博客或者论坛上已经讨论过了，但是无论如何，它都吸引了很多人的关注。所以，感谢所有花时间来阅读这篇博客的读者！对此，我真的非常感激。
 
@@ -21,7 +21,7 @@
 
 ### 上一篇文章中的挑战
 
-我不会详细介绍上一篇博客中的挑战和解决方案，因为你可以去阅读我的第一篇文章，了解所有的细节[这里](https://itnext.io/using-node-js-to-read-really-really-large-files-pt-1-d2057fe76b33)，但是我会给你进行一下简单的介绍。
+我不会详细介绍上一篇博客中的挑战和解决方案，因为你可以去阅读我的第一篇文章，在[这里](https://juejin.im/post/5d4b99eb5188257bc15d299f)可以了解所有细节，但是我会给你进行一下简单的介绍。
 
 这个挑战是来自于 Slack 频道的人发布的一个编码挑战，要求读取一个非常大的数据集（总共大小超过 2.5 GB），解析数据并且提取各种信息。
 
@@ -34,9 +34,9 @@
 
 这里是数据链接：​[https://www.fec.gov/files/bulk-downloads/2018/indiv18.zip](https://www.fec.gov/files/bulk-downloads/2018/indiv18.zip)
 
-#### 三种解决方案与小数据集情况下的不同点
+#### 三种小数据集场景下的解决方案
 
-当我努力去实现处理大型数据集这个目标的过程中，我在 Node.js 中提出了三个解决方案。
+当我努力去实现处理大型数据集这个目标的过程中，我在 Node.js 中想到了三个解决方案。
 
 **解决方案 1：[`fs.readFile()`](https://nodejs.org/api/fs.html#fs_fs_readfile_path_options_callback)**
 
@@ -48,7 +48,7 @@
 
 **解决方案 3：[`event-stream`](https://www.npmjs.com/package/event-stream)**
 
-最后，我在 Node.js 中提出了唯一能够处理完整的 2.55 GB 的文件的解决方案。
+最后，我在想到了 Node.js 中唯一能够处理完整的 2.55 GB 的文件的解决方案。
 
 > 有趣的是：Node.js 在任何时候，都只能够在内存中容纳 1.67 GB，之后就会抛出 JavaScript 的 `heap out of memory` 错误。
 
@@ -83,7 +83,7 @@ console.timeEnd('label1');
 // 输出的结果类似于这样: label1 0.002ms
 ```
 
-这是我用来计算处理数据集所需要的时间的一种方法。
+这是我用来计算处理数据集所需时间的一种方法。
 
 [**`performance-now`**](https://www.npmjs.com/package/performance-now)
 
@@ -114,13 +114,13 @@ console.log('Performance for timing for label:' + (end — start).toFixed(3) + '
 
 我想同时使用 Node 的 `console.time()` 和 `performance-now`，我可以规避差异并且获得关于文件解析函数真正的执行时间的准确值。
 
-下面是我在每个脚本中接入 `console.time()` 以及 `performance-now` 的代码片段。这些代码只是每个函数的片段 - 相对于完整代码来说，你可以在[这里](https://github.com/paigen11/file-read-challenge)查看我的代码仓库。
+下面是我在每个脚本中接入 `console.time()` 以及 `performance-now` 的代码片段。这些代码只是每个函数的片段 - 如果你想看全部代码，你可以在[这里](https://github.com/paigen11/file-read-challenge)查看我的代码仓库。
 
 **fs.readFile() 代码实现示例**
 
 ![](https://cdn-images-1.medium.com/max/2568/1*n48UZ77lvktwjN6IDR0x1g.png)
 
-由于这个脚本使用 `fs.readFile()` 实现，整个文件都会在执行函数之前被读取到内存中，看起来这是最同步的代码。但是它实际上不是同步的，同步地读取文件在 Node 中有一个专用的方法，叫做 `fs.readFileSync()`，两者看起来很相似。
+由于这个脚本使用 `fs.readFile()` 实现，整个文件都会在执行函数之前被读取到内存中，这看起来很像同步代码。但是它实际上不是同步的，同步地读取文件在 Node 中有一个专用的方法，叫做 `fs.readFileSync()`，两者看起来很相似。
 
 但是，我们很容易看到文件的总行数以及两个计时器方法，来确定执行行计数到底花费了多长时间。
 
@@ -188,7 +188,7 @@ console.log('Performance for timing for label:' + (end — start).toFixed(3) + '
 
 #### 结论
 
-最后，Node.js 原生的流和非原生的流，在处理大型数据集的时候会更加有效。
+最后，流式处理，不论是 Node.js 原生的亦或是非原生的，在处理大型数据集的时候都会更加有效。
 
 感谢你继续阅读了本系列文章的第二部分。如果你想要再次阅读第一篇文章，可以看[这里](https://itnext.io/using-node-js-to-read-really-really-large-files-pt-1-d2057fe76b33)。