Why is MinGW very slow?

Question

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

Answer 1

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

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).

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

Answer 2

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.

Another thing which suffers from this is GNU Autotools, so running ./configure scripts 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 configure to find all the libraries).

This answer explains in more detail how Cygwin and MinGW used to simulate fork(), and this answer has more up to date explanation.

Answer 3

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

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.

Answer 4

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 DLL will introduce a long delay before starting any MSYS executable (that uses MSYS DLL). This affects MSYS make and all the command-line utilities from CoreUtils package such as ls, rm etc that are typically installed in C:\MinGW\msys\1.0\bin.

Observations:

• When launching utilities from MSYS bash shell, 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 cmd and type echo %LOGONSERVER%, then ping or net view with the host name of the DC.

Why is it so slow:

• The code of MSYS DLL in 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 LOGONSERVER variable. 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.

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 LOGONSERVER with the correct DC host.
• If MSYS tools are called from Windows cmd or a script, then set LOGONSERVER to a localhost to avoid network access. E.g. set LOGONSERVER=\\LOCALHOST worked 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 cmd or 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.