← Back to context

Comment by barrkel

8 years ago

According to the MSYS2 devs, MSYS2 is slightly slower than Cygwin, and it has a significantly different project objective, leading to much reduced command-line environment:

https://stackoverflow.com/a/25755481/3712 (MSYS2 dev)

As for whether it's slower, I expect there'd be very little difference but MSYS2 would be a tiny amount slower due to the extra conversion work.

https://github.com/msys2/msys2/wiki/How-does-MSYS2-differ-fr...

MSYS2 provies a minimal shell required to run autotools and other build systems which get the source for software from the Internet from different repositories, configure them and build them. The shell and core tools exist mainly to allow porting Unix programs to run natively on Windows (i.e. without requiring a POSIX emulation layer). MSYS2 doesn't try to duplicate Cygwin's efforts more than necessary, so the number of provided POSIX-emulated software is very small.

(I recommend Cygwin, I've been using it for 15 years or so, and have access to almost everything I've ever needed from Linux command line. The slowest thing is forking; emulating it in Win32 executables is not easy on NT kernel. MSYS2 doesn't fix that.

Also, apt-cyg is pretty decent for installing packages on Cygwin.)

6 comments

barrkel

Reply
dataflow  8 years ago

Why "according to the MSYS2 devs" from 2014 though? Have you not tried MSYS2 yourself? I tried Cygwin a handful of years ago and it was worlds slower than MSYS, which I decided to use instead. I switched to MSYS2 a couple years ago or so, and it which hasn't felt any slower than MSYS. Cygwin took forever just to traverse a directory hierarchy. Has it has gotten an enormous speed boost since?

  • barrkel  8 years ago

    I briefly had a look at MSYS2 several years ago but it was all oriented around Win32 compilation. For example, I wanted an ffmpeg build, but I needed it to understand Cygwin paths, while the MSYS2 instructions are for a Win32 executable rather than Cygwin executable.

    Directory trees are indeed another thing that are not enormously fast in Cygwin, but how often do you do recursive listings of directory trees? I don't even do that often on Linux because it's not fast there either.

    Specific example: `find` has several tricks up its sleeve that it thinks are fast (e.g. looking at link counts on directories to test for leaf directories), but emulating the APIs that it uses for these tricks are part of what makes it slow on Cygwin (Cygwin will need to count the directories to emulate the link count, which makes it O(n^2) rather than O(n)). You can use -noleaf to turn this off. But `find` does other stats that make it slow.

    I use a script that wraps `cmd /c dir /b /s /a` (IIRC) and cygpath for the few scripts I have that do much recursive processing, but it's very rarely a big factor. My biggest directories are on my NAS which is Linux.

    My single biggest performance problem - as in, almost debilitating on Cygwin - are poorly written Emacs plugins that do filesystem access in the status line update callback (e.g., Projectile). But they're easily monkeypatched when they crop up.