单核Windows 7机器上的Node.js电子应用程序在文件I/O上很慢

Node.js Electron Applications for Single Core Windows 7 machines are slow on file I/O

本文关键字：文件应用程序机器 Windows Node 单核 js 更新时间：2023-09-26

我正在一台单核windows 7机器上运行一个电子应用程序。似乎每当我使用fs库执行几乎任何文件I/O时，CPU在电子过程中峰值到100%，并且执行文件I/O可能需要长达一分钟的时间。

一个特别慢的函数是fs.readFileAsync()。我正在读取的文件非常小，但是执行它似乎需要很长时间。

我也在双核的Windows 7、Windows 8.1、Windows 10和Ubuntu 15.10上运行了这段代码，这些操作系统都没有遇到这个问题，似乎只有单核的Windows 7机器才会出现这个问题。(所以我几乎肯定写的代码没有问题)。

有人知道为什么会发生这种情况吗?这个问题有什么解决办法吗?核的数量会影响电子应用程序的性能，这似乎很奇怪。同样，这只是Windows 7，所以单核Windows 8.1或Windows 10机器不会显示此行为。

Electron在主进程中不能很好地处理这样的任务。电子也不是多线程的。

即使你正在运行单核，我建议使用node的"child_process"在电子主进程之外运行文件读/写(或任何繁重的任务)。这应该可以解决应用程序中的任何奇怪的打嗝或口吃，并且通常可以加快速度。

还请记住，电子是基于chrome和节点是基于v8，这是chrome的核心。这些因素结合在一起，使得电子本质上是资源密集型的，而性能通常是电子的缺点。好处显然是能够快速创建跨平台应用。总的来说，1核机器可能不太适合运行1个电子应用程序，我们什么时候没有过1核机器?十年?

这让我想起了这个问题和我所见过的其他问题。

电子应用程序中的require("fs")实际上并没有得到Node的fs模块。它使用了Electron提供的另一个版本的fs。Electron团队的建议是在执行文件操作时使用require("original-fs")。

有一个开放的问题来记录这个:

Electron直接修改fs模块来支持ASAR文件，但是对于不需要ASAR支持的用例来说，这可能是一个性能负担，并且支持那些"原始的"用例。fs模块在require('original-fs')下可用。

如果你遇到减速，我会尝试使用original-fs。