我怎样才能加快MinGW-w 64的 * 极 * 慢的C++编译/链接?
编译一个琐碎的“Hello World”程序:
#include <iostream>
int main()
{
std::cout << "hello world" << std::endl;
}
...需要 *3分钟 *(!)在这台其他卸载的Windows 10计算机(i7-6700,32 GB的RAM,体面的SATA固态硬盘):
> ptime.exe g++ main.cpp
ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/
Copyright(C) 2002, Jem Berkes <jberkes@pc-tools.net>
=== 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
2条答案
按热度按时间evrscar21#
考虑到我无法在干净的Windows 10虚拟机中重现这个问题,以及对输出文件名的依赖,我走上了反病毒/反恶意软件干扰的道路。
fltmc instances
列出了几个可能的文件系统过滤器驱动程序;猜测-N-检查将其缩小到Carbon Black中的两个:carbonblackk
和ParityDriver
。使用Regedit通过在这两个注册表项中将
Start
设置为0x4
(“Disabled”,0x2
== Automatic,0x3
== Manual)来禁用它们,然后重新启动,修复了速度慢的问题:whlutmcx2#
要解决链接速度慢的问题,您可以使用其他链接器。
我们通过添加这个链接器选项
-fuse-ld=lld
来加速GitHub操作-fuse-ld=lld
将使用llvm链接器。例如:
LDFLAGS
的文档:将仅由CMake在第一次配置时用于确定默认链接器标志,之后LDFLAGS的值将作为CMAKE_EXE_LINKER_FLAGS_INIT、CMAKE_SHARED_LINKER_FLAGS_INIT和CMAKE_MODULE_LINKER_FLAGS_INIT存储在缓存中。对于任何配置运行(包括第一次),如果定义了等效的CMAKE__LINKER_FLAGS_INIT变量,则将忽略环境变量。_LINKER_FLAGS_INIT variable is defined.