如何加速极慢的MinGW-w64编译/链接？

Question

如何加速MinGW-w64极慢的C ++编译/链接过程?

编译一个微不足道的“Hello World”程序：

#include <iostream>
int main()
{
    std::cout << "hello world" << std::endl;
}

在这台其他情况下未加载的 Windows 10 机器上（i7-6700，32GB RAM，不错的SATA SSD），需要3分钟：

> ptime.exe g++ main.cpp

ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/
Copyright(C) 2002, Jem Berkes <[e-mail]>

===  g++ main.cpp ===

Execution time: 180.488 s

Process Explorer 显示 g++ 进程树在 ld.exe 中崩溃，持续时间内没有使用任何可感知的 CPU 或 I/O。

通过 API Monitor 运行 g++ 进程树显示 ld.exe 中有三个异常长的系统调用：两个 NtCreateFile() 和一个 NtOpenFile()，每个调用对 a.exe 进行操作，并且每个调用需要 60 秒钟。

只有当使用默认的 a.exe 输出时才会出现缓慢; g++ -o foo.exe main.cpp 最多需要 2 秒钟。

“那就不要使用 a.exe 作为输出名称！”并不是真正的解决方案，因为此行为会导致 CMake 花费很长时间进行编译器功能检测。

GCC 工具链版本：

>g++ --version
g++ (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 8.1.0

>ld --version
GNU ld (GNU Binutils) 2.30

- genpfault

---

我认为你的文件夹可能存储在网络共享上，但像@genpfault所说，这可能是个杀毒软件问题，听起来更像是它的问题。我建议a)尝试在安全模式下启动Windows。b）尝试在RamDrive文件夹上编译（我会在RamDrive上进行阴影编译以加快大型编译速度）。c）如果你将其编译为foo.exe，然后重命名为a.exe或复制到a.exe，会发生什么？它需要那么长时间吗？ - Mirko

Answer 1

鉴于我无法在干净的Windows 10虚拟机中重现问题，并且输出文件名的依赖关系让我想到了反病毒/反恶意软件干扰的可能性，fltmc instances 列出了几个可能的文件系统过滤驱动程序；猜测和检查将其缩小到两个 Carbon Black 的过滤器驱动程序：carbonblackk 和 ParityDriver。

使用Regedit通过将这两个注册表键中的Start设置为0x4（“禁用”，0x2 == 自动，0x3 == 手动）来禁用它们，然后重新启动即可解决速度慢的问题：

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\carbonblackk
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ParityDriver

- genpfault

Answer 2

为了解决链接速度慢的问题，您可以使用替代链接器。

我们通过添加此链接器选项-fuse-ld=lld加速了GitHub操作。 -fuse-ld=lld将使用llvm链接器。

示例：

run: cmake -S. -B build -G "Ninja"
env:
    LDFLAGS: "-fuse-ld=lld" # MINGW linking is very slow. Use llvm linker instead.

LDFLAGS 的文档：

CMake 只会在第一次配置时使用 LDFLAGS 来确定默认的链接器标志，之后 LDFLAGS 的值将作为 CMAKE_EXE_LINKER_FLAGS_INIT、CMAKE_SHARED_LINKER_FLAGS_INIT 和 CMAKE_MODULE_LINKER_FLAGS_INIT 存储在缓存中。对于任何配置运行（包括第一次运行），如果定义了等效的 CMAKE_<TYPE>_LINKER_FLAGS_INIT 变量，则环境变量将被忽略。

- jpr42