C++ 为什么 MinGW 很慢？

Why is MinGW very slow?

提问by Calmarius

I'm using the Code::Blocks IDE with GCC/MinGW on Windows, and I'm trying to build a wxWidgets application which has ca. 20k lines and 40 source modules. And it builds very very slow.

我在 Windows 上使用带有 GCC/MinGW 的 Code::Blocks IDE，我正在尝试构建一个 wxWidgets 应用程序。20k 行和 40 个源模块。它的构建非常非常缓慢。

Compiling a C++ module lasts 2-5 seconds, and linking lasts even 2-3 minutes.

编译一个 C++ 模块需要 2-5 秒，链接甚至需要 2-3 分钟。

It's a portable code, and this code compiles very fast on Linux. I can't follow the build message window... The entire process lasts less than 20 seconds.

这是一个可移植的代码，并且这段代码在 Linux 上编译得非常快。我无法按照构建消息窗口...整个过程持续不到 20 秒。

I tried the common tweaks (for example, precompiled header, turn optimizations off, etc.), but nothing worked.

我尝试了常见的调整（例如，预编译头、关闭优化等），但没有任何效果。

Why is it so slow?

为什么这么慢？

回答by mdaniel

Are you on an Active Directory domain, but not immediately connected to it?

您是否在 Active Directory 域中，但没有立即连接到它？

While I don't have the "answer" as to why MinGW would be slow, it has been my experience that computers which belong to an AD domain, but are unable to reach the AD controller, have a delay in starting executables (such as rxvt.exe) and currently running ones experience a pause or stutter (such as emacs, which is built using MinGW).

虽然我不知道为什么 MinGW 会很慢，但我的经验是，属于 AD 域但无法访问 AD 控制器的计算机在启动可执行文件（例如rxvt.exe）和当前正在运行的程序会遇到暂停或卡顿（例如使用 MinGW 构建的 emacs）。

I am still investigating to determine the actual causeof this behavior, but thought I would mention it in case it applies to you.

我仍在调查以确定这种行为的实际原因，但我想我会提到它，以防它适用于您。

回答by hyde

Many "unixy" things on MinGW are painfully slow, because Windows has no fork(). Windows only has CreateProcess(), which is quite different. Unix shells and GNU Make do a lot of forking, so running these under MinGW results in "emulated" forks, which are really slow.

MinGW 上的许多“unixy”东西都非常缓慢，因为 Windows 没有fork(). Windows 只有CreateProcess()，这是完全不同的。Unix shells 和 GNU Make 做了很多分叉，所以在 MinGW 下运行这些会导致“模拟”分叉，这真的很慢。

Another thing which suffers from this is GNU Autotools, so running ./configurescripts when building "unixy" applications from sources is also very slow. This can get really annoying if you need to do it many times (for example when having troubles with with getting configureto find all the libraries).

受此影响的另一件事是 GNU Autotools，因此./configure在从源构建“unixy”应用程序时运行脚本也很慢。如果您需要多次执行此操作（例如，在通过配置查找所有库时遇到问题时），这会变得非常烦人。

This answerexplains in more detail how Cygwin and MinGW used tosimulate fork(), and this answerhas more up to date explanation.

这个答案更详细地解释了 Cygwin 和 MinGW 如何用来模拟fork()，这个答案有更多最新的解释。

回答by AlexF

As of MSYS 1.0.19-1, if the user account is in Active Directory domain and the Domain Controller (DC) is unreachable, then MSYS DLLwill introduce a long delay before starting any MSYS executable (that uses MSYS DLL). This affects MSYS makeand all the command-line utilities from CoreUtils package such as ls, rmetc that are typically installed in C:\MinGW\msys\1.0\bin.

从 开始MSYS 1.0.19-1，如果用户帐户在 Active Directory 域中并且域控制器 (DC) 无法访问，则MSYS DLL在启动任何 MSYS 可执行文件（使用MSYS DLL）之前会引入很长的延迟。这会影响MSYSmake和所有Coreutils的命令行实用程序包，例如ls，rm等等，其通常安装在C:\MinGW\msys\1.0\bin。

Observations:

观察：

• When launching utilities from MSYS bashshell, only the shell's startup is hit by the delay. Utilities launched from the shell are not impact.

• The delay can vary, in my case it is 21sec.

• Running any MSYS utility within 10-20sec after the delayed command will launch without a new delay.
• Problem occurs when the machine is connected to a different network, or when disconnected from its domain, or when Domain Controller hostname changes (problem in my case). To check if DC is reachable, open cmdand type echo %LOGONSERVER%, then pingor net viewwith the host name of the DC.

• 从 MSYS bashshell启动实用程序时，只有 shell 的启动会受到延迟的影响。从 shell 启动的实用程序不会受到影响。

• 延迟可能会有所不同，在我的情况下是 21 秒。

• 在延迟命令后 10-20 秒内运行任何 MSYS 实用程序将启动而不会出现新的延迟。
• 当机器连接到不同的网络时，或与域断开连接时，或域控制器主机名更改时（在我的情况下是问题），就会出现问题。要检查 DC 是否可访问，请打开cmd并键入echo %LOGONSERVER%, 然后ping或net view与 DC 的主机名。

Why is it so slow:

为什么这么慢：

• The code of MSYS DLLin uinfo.cc internal_getlogin()makes two system calls to get user information. First time it calls NetUserGetInfo()to retrive the user account from the local machine. It fails for domain users, so it calls it second time with the DC server taken from LOGONSERVERvariable. If this host is not immediately accessible, it will introduce a long delay until the call fails on timeout. The application will start shortly after.

• MSYS DLLin的代码进行了uinfo.cc internal_getlogin()两次系统调用以获取用户信息。第一次调用NetUserGetInfo()以从本地计算机检索用户帐户。它对域用户失败，因此它使用从LOGONSERVER变量中获取的 DC 服务器第二次调用它。如果该主机不能立即访问，它将引入很长的延迟，直到超时调用失败。该应用程序将在不久之后启动。

How to avoid this problem, several workarounds:

如何避免这个问题，有几种解决方法：

• Either run everything from MSYS shell, or
• If the reason is the change in DC hostname, then a restart or re-login will resolve the issue. Windows will automatically update LOGONSERVERwith the correct DC host.
• If MSYS tools are called from Windows cmdor a script, then set LOGONSERVERto a localhost to avoid network access. E.g. set LOGONSERVER=\\LOCALHOSTworked for me. Note: this variable is set at logon and changing it globally in Windows Environment Variables window has no effect compared to setting it in cmdor a script.
• I consider this a bug in MinGW/MSYS. The code in MSYS2 and Cygwin is different. I checked MSYS2 and it has no such issue.

• 从 MSYS shell 运行所有内容，或者
• 如果原因是 DC 主机名的更改，则重新启动或重新登录将解决该问题。Windows 将LOGONSERVER使用正确的 DC 主机自动更新。
• 如果从 Windowscmd或脚本调用 MSYS 工具，则设置 LOGONSERVER为 localhost 以避免网络访问。例如set LOGONSERVER=\\LOCALHOST为我工作。注意：这个变量是在登录时设置的，在 Windows 环境变量窗口中全局更改它与在cmd脚本中设置它相比没有任何影响。
• 我认为这是 MinGW/MSYS 中的一个错误。MSYS2 和 Cygwin 中的代码是不同的。我检查了 MSYS2，它没有这样的问题。

回答by SurvivalMachine

You can try to use a more recent version of the toolset. I found this to be useful: http://nuwen.net/mingw.htmlIt has all the tools used by MinGW and common APIs in a single big package. From the site:

您可以尝试使用更新版本的工具集。我发现这很有用：http: //nuwen.net/mingw.html它在一个大包中包含 MinGW 使用的所有工具和通用 API。从网站：

My MinGW distribution ("distro") is x64-native and currently contains GCC 6.1.0 and Boost 1.61.0.

MinGW is a port of GCC to Windows. It is free of charge and simple to use (well, as simple as toolchains ever get). It produces standalone Windows executables which may be distributed in any manner.

我的 MinGW 发行版（“发行版”）是 x64 原生的，目前包含 GCC 6.1.0 和 Boost 1.61.0。

MinGW 是 GCC 到 Windows 的端口。它是免费的且易于使用（嗯，就像工具链一样简单）。它生成可以以任何方式分发的独立 Windows 可执行文件。