Why is Windows so slow?

Wow, so if you want to test file system speeds, you do it by listing files - I know this just an example, but perhaps it has something to do with the speed of the terminal?

There are a plethora of disk benchmarking tools - I doubt that they consistently show 40x differences.

Hooves -> horses, and all that.

There is indeed marked differences between unix terminals - xterm is blazingly fast. Do the same test the author did with xterm and with another terminal and you'll see significant differences. cmd may just be a slow terminal masking actual windows speed.

Maybe I'm misunderstanding (or he's since changed his post), but:

    dir /s > c:\list.txt

is piping it into a file. Where does the speed of the terminal affect that (in any significant fashion)? I know what you're getting at - tar --verbose can slow things down for me by sometimes a factor of 2 (for huge tarballs), but I don't think it's an issue in this situation.

Huh? He redirected the output to a file, so terminal speed doesn't really factor in here.

Yes, I saw the redirection. But "dir" is an built-in command in the Windows shell; is the speed of that command a benchmark-able number? Is the point to compare the speed of "ls" vs "dir", or the underlying OS/file-systems (i.e., posix vs. win32 /Ext3 vs. NTFS)? If someone tells me that "dir" is slow, I'd agree -- but that -- in itself -- doesn't imply that the filesystem is slow.

It might be, actually, since dir is a command built into cmd.exe on Windows, not a separate .exe that gets run. It may be smarter to use "ls" from cygwin for the test.

True, I agree it's not necessarily a good way to test the filesystem, but it's only the shell that's being hit, nothing really to do with the terminal.

I pointed it out mainly because terminals can have a significant impact on performance, because dumping millions of lines a second isn't their intended purpose,[1] whilst the shell can be reasonably expected to do that.

Having it entirely as a shell built-in possibly actually better than the equivalent '/bin/ls > somefile' since it doesn't need to context switch back and forth as the stdout buffer fills up and the shell has to write it.

[1] I recall there being a Gentoo-related thread about why "Gentoo-TV" -- having the output of gcc scroll past as your background with a transparent xterm -- was actually slowing down package builds significantly.

If it's unreasonable to assume a 30-year old command extending directly back to MS-DOS 1.0 has never had anybody once take a look at making sure it isn't unreasonably slow, well, I think there's some reasonable conclusions we can draw from that with regards to performance on Microsoft products.

I will never, ever understand the downmodding on this site. There is no particular opinion in this statement - it's an informative statement that the speed of your terminal can matter. I find it strange that on a site claiming to be for hackers that a fairly opinion-free comment on terminal speed differences gets downmodded.

It's hard to keep a thick skin about having your voice diminished when even your informative, unopinionated stuff gets shut down.