←back to thread

Why is Windows so slow?

(games.greggman.com)
337 points kristianp | 2 comments | 19 Dec 11 06:56 UTC | HN request time: 0.419s | source
Show context
portman ◴[19 Dec 11 17:08 UTC] No.3370217[source]▶
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.

replies(4): >>3370373 #>>3370537 #>>3370628 #>>3371306 #
coverband ◴[19 Dec 11 17:52 UTC] No.3370373[source]▶
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.
replies(1): >>3370762 #
1. ajross ◴[19 Dec 11 19:24 UTC] No.3370762[source]▶
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.

replies(1): >>3371145 #
2. barrkel ◴[19 Dec 11 21:06 UTC] No.3371145[source]▶
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.