←back to thread

Why is Windows so slow?

(games.greggman.com)
337 points kristianp | 1 comments | 19 Dec 11 06:56 UTC | HN request time: 0.233s | source
Show context
jstclair ◴[19 Dec 11 07:48 UTC] No.3368887[source]▶
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.

replies(4): >>3368895 #>>3368913 #>>3368916 #>>3369136 #
shabble ◴[19 Dec 11 08:00 UTC] No.3368913[source]▶
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.
replies(1): >>3369131 #
jstclair ◴[19 Dec 11 09:59 UTC] No.3369131[source]▶
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.
replies(2): >>3369225 #>>3369942 #
1. shabble ◴[19 Dec 11 10:50 UTC] No.3369225[source]▶
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.