我知道这不是一个编程问题，但它是相关的。
我的工作相当large cross platform project .在 Windows 上，我使用 VC++ 2008。在 Linux 上，我使用 gcc。项目中有大约 40k 个文件。在编译和链接同一项目时，Windows 比 Linux 慢 10 到 40 倍。我该如何解决？
在 Linux 上一次更改增量构建需要 20 秒，在 Windows 上需要 3 分钟以上。为什么？我什至可以在 Linux 中安装“黄金”链接器，并将时间缩短到 7 秒。
同样，git 在 Linux 上的速度比 Windows 快 10 到 40 倍。
在 git 情况下，git 可能不是以最佳方式使用 Windows，而是 VC++？你会认为微软希望让他们自己的开发人员尽可能地高效，而更快的编译将在很大程度上实现这一目标。也许他们正试图鼓励开发人员使用 C#？
作为简单的测试，找一个有很多子文件夹的文件夹，做一个简单的
dir /s > c:\list.txt
在 Windows 上。执行两次并为第二次运行计时，以便从缓存中运行。将文件复制到 Linux 并执行等效的 2 次运行并为第二次运行计时。
ls -R > /tmp/list.txt
我有 2 个规范完全相同的工作站。 HP Z600s 配备 12gig 内存，8 核，频率为 3.0ghz。在包含约 400k 个文件的文件夹上，Windows 需要 40 秒，Linux 需要
是否可以设置注册表设置来加速 Windows？什么给了？
一些稍微相关的链接，与编译时间相关，不一定是 i/o。
显然是 there's an issue in Windows 10 (not in Windows 7) that closing a process holds a global lock .当使用多个内核进行编译时，因此会出现多个进程。
The /analyse option can adversely affect perf because it loads a web browser . (此处不相关，但很高兴知道)
最佳答案
除非有铁杆 Windows 系统黑客出现，否则你只会得到党派评论(我不会这样做)和猜测(这是我要尝试的)。
文件系统 - 您应该在同一个文件系统上尝试相同的操作(包括 dir)。我遇到了this它对一些文件系统的各种参数进行了基准测试。
缓存。我曾经尝试在 RAM 磁盘上运行 Linux 上的编译，发现由于内核处理缓存的方式，它比在磁盘上运行要慢。这是 Linux 的一个可靠卖点，并且可能是性能如此不同的原因。
Windows 上的错误依赖规范。也许 Windows 的 chromium 依赖规范不像 Linux 那样正确。当您进行小的更改时，这可能会导致不必要的编译。您或许可以在 Windows 上使用相同的编译器工具链来验证这一点。
https://stackoverflow.com/questions/6916011/