#1476 MSYS make is 60X slower than before


MSYS make 3.82 is now 60X slower than earlier make programs. When building GraphicsMagick, it takes 2.5 minutes before make does any work or decides there is nothing to be done. After make has decided what to do, the build proceeds normally. It normally takes a couple of seconds before make decides what needs to be done. With a Cygwin installation on the same machine using the same source files and same build parameters, make decides there is nothing to be done in about two seconds. The build is done with the source files accessed via CIFS to a fast server and object files written locally. Using 'make -d' shows that there are about 340K rules which are tested, without any noticeable pauses or slowness due to server access.

Charles Wilson tells me that make now tests various permutations of upper and lower case in order to handle filesystems which don't preserve case. This approach would certainly dramatically multiply the number of filesystem acceses and may explain the dramatic slowdown. I also notice that make 3.82 tests about twice as many implicit rules than make 3.81 does.


  • Bob Friesenhahn

    Bob Friesenhahn - 2010-09-21

    My error. It is indeed 3.81:

    $ make --version
    GNU Make 3.81
    Copyright (C) 2006 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.
    There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A

    This program built for i686-pc-msys

  • Bob Friesenhahn

    Bob Friesenhahn - 2011-04-23

    I finally got back to this since today I am using MinGW and it is driving me crazy. The 'csmake' program runs vastly faster than the standard MinGW 'make' to decide to do nothing for a GraphicsMagick build:

    bfriesen@optiplex755 ~/mingw/GM-16-static
    $ time make
    make all-am
    make[1]: Entering directory `/home/bfriesen/mingw/GM-16-static'
    make[1]: Leaving directory `/home/bfriesen/mingw/GM-16-static'

    real 2m14.689s
    user 0m5.295s
    sys 0m40.890s

    bfriesen@optiplex755 ~/mingw/GM-16-static
    $ time csmake
    csmake all-am
    csmake[1]: Entering directory `/home/bfriesen/mingw/GM-16-static'
    csmake[1]: Leaving directory `/home/bfriesen/mingw/GM-16-static'

    real 0m2.562s
    user 0m0.858s
    sys 0m0.921s

  • Bob Friesenhahn

    Bob Friesenhahn - 2011-04-23

    I should mention that GraphicsMagick uses a non-recursive Automake build configuration so that source file name specifications including a directory component when building. The source files reside on a fast Samba server but the build directory is hosted by the Windows system.

  • Earnie Boyd

    Earnie Boyd - 2011-04-23

    To eliminate the possibility of data caching affecting the timings you need to reboot your computer and enter csmake command first.

    $ time ls /bin
    real 0m0.469s
    user 0m0.030s
    sys 0m0.154s

    $ time ls /bin
    real 0m0.391s
    user 0m0.030s
    sys 0m0.093s

    As you can see the second occurrence uses much less system time. Although I doubt you'll see a big improvement over 2m for make.

  • Bob Friesenhahn

    Bob Friesenhahn - 2011-04-23

    To put things in perspective, here is the total package build time from 'csmake -j 4' on the same system:
    real 0m46.391s
    user 1m15.990s
    sys 0m41.554s
    With csmake, the whole package could build from scratch in the time that it takes for 'make' to visibly start doing anything at all.

  • Bob Friesenhahn

    Bob Friesenhahn - 2011-04-23

    Earnie, I relish data caching, and quite rarely reboot computers. Caching is good. My timings are done with anything that can be cached already cached on the client system The file server has 20GB of RAM so it also does lots of caching. Since the software builds fine using 'csmake' there is no need for any case-insensitive code to be used.

  • Earnie Boyd

    Earnie Boyd - 2011-04-25

    I was just trying to eliminate possibilities. I agree with you, IIRC csmake was added as a result of conversations I had made on one of the lists (mingw-users or mingw-dvlpr). Solution to your problem is to set in your ~/.profile file ``alias make=csmake'' and let's be done with the conversation. I would encourage you though to create a wiki post of your findings and the solution to the issue I've given you.

    Keith and Cesar, do you think we should close as won't fix or do you think we should reverse the decision to include the case insensitive patch as the default make for MSYS and instead of csmake have one that is named cimake?

  • Earnie Boyd

    Earnie Boyd - 2011-04-25
    • milestone: --> Known_Feature
    • status: open --> pending
  • Bob Friesenhahn

    Bob Friesenhahn - 2011-04-25

    Since Windows is case-preserving, I tend to wonder about the decision for 'make' to be case insensitive by default. It seems like a bad idea to me since those developing projects primarily under MinGW but with a desire to be portable to other systems (e.g. Linux, or even Cygwin) will potentially produce projects which don't work at all due to case issues.

    My project (GraphicsMagick) is open sourced and soon I will be encouraging users to build it from source on MinGW rather than MSVC. If 'make' seems incredibly slow, I will soon hear complaints.

    Regardless, I did already add a shell alias in order to improve my personal efficiency.

  • Bob Friesenhahn

    Bob Friesenhahn - 2011-04-25
    • status: pending --> open
  • Earnie Boyd

    Earnie Boyd - 2011-04-25

    Case preserving case insensitive file name operation is the issue. Yes, it preserves case but files named FOO, Foo, fOO, fOo and foo will all be found regardless of the reference. The patch allows for non-matching targets to be considered so that the target FOO doesn't build if foo is found and is up-to-date. Frankly, I have never had an issue with make without the patch.

  • Keith Marshall

    Keith Marshall - 2011-04-26

    case preserving != case sensitive

    The windows file system is case insensitive, pretending otherwise can have serious, (and for all practical purposes, insoluble), consequences. Pattern rules such as

    %.$(OBJEXT): %.c

    will fail dramatically, if the compiler doesn't strictly honour the case preserving concept; even for an 8.3 file name, the number of permutations of this rule which must be written, if you try to pretend that

    case preserving == case sensitive

    becomes prohibitive. YOU may not have encountered this issue, but I have; indeed, it is the fundamental reason why cygwin was rejected out of hand, for porting a legacy DJGPP application, in my day job; (cygwin's make promotes the case preserving == case sensitive fiction, as did early MSYS builds).

    Granted, problems are more likely to arise with legacy MS-DOS applications, than with anything developed from scratch, for more modern WinNT based platforms. When I first raised the issue, several years ago, it was a serious problem for me; the solution was to ensure that make was built with its CASE_INSENSITIVE_FILESYSTEM option enabled. It would be less of an issue for me today, because I no longer have to maintain that legacy application. However I still believe it is important that we continue to offer a make which does respect the true case insensitive nature of the file system.

    When we first addressed the issue, we offered two variants of make; the default was built with CASE_INSENSITIVE_FILESYSTEM, (which I still believe to be the safest option), and the alternative called csmake was offered for those who wished to promulgate the case preserving == case sensitive fiction.

    Later, Cesar devised the current hybrid build, which attempts to be all things to all men. It seemed like a good idea, at the time. Maybe the speed issue is just too serious a detraction, and we should revert to the two alternative choices, leaving users to decide which is most suitable for them to install as make.exe

  • Earnie Boyd

    Earnie Boyd - 2013-02-08
    • labels: MSYS --> make, decide
    • milestone: Known_Feature --> MSYS
    • type: --> Task
    • resolution: --> none
    • category: --> Unknown
    • patch_attached: --> False
  • Bob Friesenhahn

    Bob Friesenhahn - 2013-02-08

    Is it reasonable for MSYS 'make' to be case-sensitive by default but add a command-line option to enable case-insensitivity? In fact, it would be useful if MSYS make had a mode where it could report case issues to the user and suggest renaming files so that the project is coherent and can work on case-sensitive operating systems.

    I continue to experience satisfaction with using 'csmake' as an alternative. Since my original bug report, the client system has been updated from Windows XP to Windows 7.

    My network server is running Samba, which I think already supports case-insensitivity on the server side even though the server OS is case-sensitive. This likely adds to the overhead.

  • Freddie Chopin

    Freddie Chopin - 2013-02-16

    If anyone cares, I'd also be "for" reverting the change that caused these problems. csmake should be default, MSYS project can provide cimake for people dealing with any problems related to this case. There are more and more people reporting this issue (as they upgrade their MSYS version) and not all of them find this topic which seems to be the only source of knowledge about the root cause.

    I've also never had any problems with previous behavior and after quickly switching to csmake after facing the issue I still have no problems (; For a project that had just a few dozen files in a few directories make was "thinking" for 30 seconds just to tell me there's nothing to do, and the project itself takes less than 30s for a complete build (excluding the "thinking" time of case insensitive make), so this behavior is really unacceptable...

    Last edit: Freddie Chopin 2013-02-16
  • Earnie Boyd

    Earnie Boyd - 2013-02-16

    Of course the other option is to work on the make code so that case insensitive comparisons don't take as much time. The case insensitiveness is more than just file names, it has to be insensitive to all targets and all dependencies. The string conversion can take quite a bit of time and as I've argued before, isn't really needed since the file system is case preserving but the argument is that case preserving != case sensitivity since a target can exist in a different case. So a target of Foo and a target of FOO in a case insensitive make would both be satisfied if fOo exists while neither is satisfied in a case sensitive make if fOo exists and the commands would be executed for both Foo and FOO targets.

  • Bob Friesenhahn

    Bob Friesenhahn - 2013-02-16

    Normal 'make' behavior is to do a 'stat' on all possible origin names to produce the target. If the problem was the time to do string compares then the overhead would be constant. However, the overhead is not constant. This tells me that 'make' is doing 'stat' on all permutations of varying-case possible origin names so that it becomes very sensitive to the time to perform each 'stat'. A 'stat' on a local file is fast because the local OS knows if the file exists and knows its current time-stamp but a 'stat' on a remote file needs to do network transactions to see if the file exists and to obtain its time-stamp.

    • Freddie Chopin

      Freddie Chopin - 2013-02-16

      "A 'stat' on a local file is fast because the local OS knows if the file exists and knows its current time-stamp but a 'stat' on a remote file needs to do network transactions to see if the file exists and to obtain its time-stamp."

      It's not true - I do only local builds and case-insensitive make takes 30 seconds just to start doing something (or nothing - if the project is up to date). For an average user it does not matter if make is case preserving, case sensitive or not, whether it's the same thing or not, as pretty much everyone knows Windows is case insensitive so trying to achieve sth else via make is prety much nonsense, and the result is software which just kills the CPU and HDD for half a minute to do nothing. Also I guess everyone knows to use only lowercase letters for filenames and that doing otherwise is asking for trouble. Currently all users of stock make.exe from MSYS have to face an extreme slowdown just because 0.00001% of users have some crazy project with crazy filenames, so I guess that it should be the other way around...

  • Bob Friesenhahn

    Bob Friesenhahn - 2013-02-16

    I am glad to hear that others are suffering do to this as well, and not just me. Thanks for the useful information.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks