Why is Windows so slow?

I'm disappointed HN! There is a lot of pontificating, but not much science here.

It takes all of 2 minutes to try this experiment yourself (plus ~8 minutes for the download).

1. Download chromium http://chromium-browser-source.commondatastorage.googleapis....

2. Unzip to a directory

3. Create this batch file in the src directory, I called mine "test.bat"

    echo start: %time% >> timing.txt
    dir /s > list.txt
    echo end: %time% >> timing

4. Run test.bat from a command prompt, twice.

Paste your output in this thread. Here is mine:

    start: 12:00:41.30 
    end: 12:00:41.94 
    start: 12:00:50.66 
    end: 12:00:51.31 
    

First pass: 640ms; Second pass: 650ms

I can't replicate the OP's claim of 40000ms directory seek, even though I have WORSE hardware. Would be interested in other people's results. Like I said, it only takes 2 minutes.

Unfortunate that this comment doesn't get enough attention in this thread... A single person's experience will always be subjective (even with the provided technical detail). If it's not consistently repeatable, it can only be used as an anectode.

Wow, you are awesome for posting facts! I have often wondered if it was some systemic thing about the centrally-managed setups of Windows at Google that was making the Chrome build suck so much (such as some aggressive antivirus, as people often suggest in these situations). My recollection is that people run into the same slow build problems on non-Google-owned Windows computers, but perhaps that "slow" is a different slow than the OP's problem.

(For comparison, I have an older checkout on this Linux laptop. It's around 145ms to list, and it's 123k files. The original post mentions 350k files, which is a significantly different number. It makes me wonder if he's got something else busted, like "git gc" turned off, creating lots of git objects in the same directory producing some O(n^2) directory listing problem. But it could just as well be something like build outputs from multiple configurations.)

Try 'fsutil disablelastaccess 0'. Not sure if that's the case for the OP, but lastaccess is horrible on performance.

I'm not sure what your point is. The post you're replying to is no less anecdotal. Obviously there are complicated performance interactions afoot here. In the OP's opinion (and mine) Windows is littered with these kinds of booby traps. Things usually work fast ... until they don't, and you have to dig hard to figure out why.

For the most part, Linux just doesn't do that. Obviously there are performance bugs, but they get discussed and squashed pretty quickly, and the process is transparent. On the occasions I'm really having trouble, I can generally just google to find a discussion on the kernel list about the problem. On windows, we're all just stuck in this opaque cloud of odd behavior.

If something is slow with respect to the OS, you can often break out procmon and examine the stacks of the poorly performing requests; or if something is stalled, you can do the same with procexp. With dbghelp configured correctly, you get symbol resolution in the OS libraries, so you can see what's going on. Worst comes to worst, you can step through the disassembly with a debugger, but it's not often required.

When I have problems with Linux, I tend to have to fall back to strace or an equivalent, and I find it harder to figure out what's going on. On Solaris, if I can find the right incantations to use with dtrace, I can see where the problems are, but it's easy to get information overload.

My point is, how opaque your perspective is depends on your familiarity with the system. I have less trouble diagnosing holdups on Windows than I do on other systems. That's because I've been doing it for a long time.

Macbook Pro (i7) with Vertex 3 SSD running Win7x64

start: 16:53:40.21 end: 16:53:53.18

start: 16:53:56.27 end: 16:54:09.31

(windows shows 283,871 files)

I think you mean 'fsutil behavior set disablelastacces 1' to disable last file access update.

Yes, I did - thank you for pointing that out.