just use cygwin
Also, AFAIK there is no 64bit version yet, which for me is a dealbreaker (I often work with files larger than 2GB).
Cygwin commands that run slower than Windows counterparts are typically those that are syscall heavy, where those syscalls are significantly different on Windows and need lots of work for emulation. The biggie is fork(); it's better by far to write scripts etc. in such a way that they stream results rather than iterate and create new processes.
So, for example, rather than write a script that converts Unix paths to Windows paths with iterated calls to cygpath -w, instead pipe the paths to cygpath -w -f -. Rather than use pipe-to-sed (like "$(echo $foo | sed 's|bar|baz|')") for ad-hoc edits, try to use shell substitutions instead (like "${foo/bar/baz}").
Another thing that can be slower in Cygwin is find, when run over very large directory trees. I wrote a wrapper script (I call it rdir) that runs "cmd.exe /c dir /b" and massages the output into a Cygwin-style format. I also have the same script written in terms of find, so that my scripts that use it work on Windows, Solaris, Linux and OS X.
But I have to say, the biggest limiting factor in me solving ad-hoc problems is composing the tools available, rather than the actual runtime speed of the tools themselves. Having all the Unix tools available makes my life far easier in this respect. They could be even slower, and I wouldn't mind, because I would still be saving lots of time compared to what Windows provides; and my scripts usually also work on all my other systems running different OSes.
PowerShell doesn't even support simple fork-join like bash does trivially:
for x in {1..10}; do (sleep $x; echo $x) & done; wait
Even ls, or wc -c report bogus results with >2GB files. less does not work even if I want to look at just the first few hundreds of lines (and "head -n 1000 | less" is a horrible workaround).
> Cygwin commands that run slower than Windows counterparts are typically those that are syscall heavy
Most unix commands are syscall/filesystem/IO heavy, after all they are file utilities. What you say with find is exactly what I'm talking about. I find that the unix tools ported to Win32 and compiled with mingw are significantly faster.
$ cmd /c dir k.txt
Volume in drive C is CobraRoot
Volume Serial Number is 02D8-502C
Directory of C:\Users\barrkel\AppData\Local\Temp
2012-07-01 15:24 31,292,160,000 k.txt
1 File(s) 31,292,160,000 bytes
0 Dir(s) 142,087,471,104 bytes free
$ du -h k.txt
30G k.txt
$ ls -l k.txt
-rw-r--r--+ 1 barrkel None 31292160000 Jul 1 15:24 k.txt
$ wc -c k.txt
31292160000 k.txt
$ time wc -l k.txt
6400000000 k.txt
real 1m5.651s
user 0m46.207s
sys 0m8.642s
$ less k.txt
PS: It's the mingw tools that don't work properly! I tried it a couple of times, but all the incompatibilities made me give up pretty quickly.
The biggest problem - and what I suspect is happening to you - is when you have third-party programs and utilities that interfere with Cygwin, most often by putting an older or newer version of cygwin1.dll on the $PATH (i.e. you may be using Cygwin as part of some other program and not be aware of it). Cygwin uses shared memory; multiple versions of cygwin1.dll disagree on the format of this shared memory, and things go pear-shaped pretty quickly from there.
Also some antivirus programs can trip up Cygwin; in its emulation, it sometimes has cause to open, close then open files in quick succession, but AV programs sometimes analyse files when they are opened by programs, and cause bogus timing-dependent sharing errors.
In any event, I much prefer Cygwin to the alternatives.
The rot tends to set in as I install packages to Cygwin; the more I add, the slower and less stable Cygwin seems to become, to the point of taking tens of seconds to reach a prompt after opening. Make of that what you will.
"Also some antivirus programs can trip up Cygwin"
That could well be a contributing factor in my case.
[1] http://cfc.kizzx2.com/index.php/tag/cygwin-slow-performance-...
I haven't bothered re-installing cygwin since the last nuke-and-pave, but I'll bear that in mind if I do and it's still relevant.
There is a tool to rebase everything, and it's usually started after install. It's possible that after you have recompiled your own apps/dlls they might need rebasing too (speaking as a cygwin user, not developer).
The only thing that I found annoying in cygwin, is that I can't use all commands from the cmd.exe, because they make sense only under cygwin. For example "gcc" is just a cygwin symbolic link to "gcc-something.exe", and when you "run it" it gives "Access denied". The workaround is to run like this: sh -c "gcc <args>" from cmd.exe
But it might solve very hard problems, for example - redis (from antirez's depot) compiled with cygwin worked for me, and although there is much better windows version by the MSOpenTech guys, it just shows that sometimes it might be the only reasonable way. The other app that comes in mind is rsync.
The NT kernel supports forking, but the Win32 subsystem does not. Because Interix lives outside the Win32 subsystem, it can provide a proper fork() implementation, whereas Cygwin has to live with its somewhat brittle emulation.
I don't see Microsoft adding forking support to the Win32 subsystem any time soon, so you'd end up rewriting Cygwin from scratch by reverse engineering Interix...