Live data from Hacker News

Why is Windows so slow?

games.greggman.com

41–50 of 159 posts

Re: Why is Windows so slow?

#41
post #27
post #14

Here is a link from the comments: NTFS Performance Hacks - http://oreilly.com/pub/a/windows/2005/02/08/NTFS_Hacks.html

Not sure about the other things, but this The default cluster size on NTFS volumes is 4K, which is fine if your files are typically small and generally remain the same size. But if your files are generally much larger or tend to grow over time as applications modify them, try increasing the cluster size on your drives to 16K or even 32K to compensate. That will reduce the amount of space you are wasting on your drive…

That's not the point he's trying to make. Smaller cluster sizes leads to larger amounts of file-system metadata keeping track of where those clusters are laid out on disk, as well as the overhead of generating, accessing, and updating those data structures.

Re: Why is Windows so slow?

#42
post #35
post #31

Interestingly enough Joel Spolsky mentioned something related to the directory listing problem more than 10 years ago. See: http://www.joelonsoftware.com/articles/fog0000000319.html In Joel's opinion it is an algorithm problem. He thinks that there is an O(n^2) algorithm in there somewhere causing trouble. And since one does not notice the O(n^2) unless there are hundreds of files in a directory it has not been fixed…

I don't think there's an O(n^2) algorithm in there. I just created a directory with 100,000 entries. Listing it (from Cygwin, no less, using 'time ls | wc') takes 185 milliseconds. The directory is on a plain-jane 7.2k 1TB drive, though of course it's hot in cache from having been created. 'dir > nul', mind you, is quite a bit slower, at over a second.

You only did one test, so you have no idea what the complexity curve is. Do at least three tests, with 1000, 10,000 and 100,000 entries and graph the results. Three tests is still pretty skimpy to figure out what the curve is, so do tests at 10 different sizes.

Also, Joel's complaint was about the Windows Explorer GUI (specifically, opening a large recycle bin takes hours). Cygwin `ls` is using a completely different code path. Your experiment does suggest that Joel's problem is in the GUI code, though, and not the NTFS filesystem code.

Re: Why is Windows so slow?

#43
Maybe this has something to do with the file indexer? 2 years ago I heard a lot of XP users complain that Windows was suddenly getting very slow. After some digging around I noticed that they turned on the file indexer by default after an update. Since then I always turn it of (properties of your disk) and shut down the service (Indexing Service).

Re: Why is Windows so slow?

#44
post #10

I don't know this poster, but I am pretty familiar with the problem he's encountering, as I am the person most responsible for the Chrome build for Linux. I (and others) have put a lot of effort into making the Linux Chrome build fast. Some examples are multiple new implementations of the build system ( http://neugierig.org/software/chromium/notes/2011/02/ninja.h... ), experimentation with the gold linker (e.g. measu…

What is preventing you from using MinGW? That way, you could use the GNU toolchain (Make, GCC, Binutils etc.) and still have full access to the Win32 API. You could reuse almost all of your Unix build scripts, and the rest boils usually down to making your scripts aware of different file extensions (.exe/.dll instead of /.so).

Even better, you can do cross compiling with MinGW. So if your toolchain dosn't perform well on Windows, just use GCC as a cross compiler and build your stuff on a Linux or BSD machine. Then use Windows for testing the executable. (On smaller projects, you usually don't even need Windows for that, since Wine does the job as well.)

(Full disclosure: I'm the maintainer of a Free Software project that makes cross compiling via MinGW very handy: http://mingw-cross-env.nongnu.org/)

Re: Why is Windows so slow?

#45
post #31

Interestingly enough Joel Spolsky mentioned something related to the directory listing problem more than 10 years ago. See: http://www.joelonsoftware.com/articles/fog0000000319.html In Joel's opinion it is an algorithm problem. He thinks that there is an O(n^2) algorithm in there somewhere causing trouble. And since one does not notice the O(n^2) unless there are hundreds of files in a directory it has not been fixed…

Along the same line, I've never understood Windows' propensity to swap out the kernel. I might have tons of free memory and half my kernel is swapped out. In fact, I've never figured out how to get it not swapped out, no matter how much memory I put in.

Re: Why is Windows so slow?

#46
post #27
post #14

Here is a link from the comments: NTFS Performance Hacks - http://oreilly.com/pub/a/windows/2005/02/08/NTFS_Hacks.html

Not sure about the other things, but this The default cluster size on NTFS volumes is 4K, which is fine if your files are typically small and generally remain the same size. But if your files are generally much larger or tend to grow over time as applications modify them, try increasing the cluster size on your drives to 16K or even 32K to compensate. That will reduce the amount of space you are wasting on your drive…

How is a 100 byte file a valid refutation of what you quoted? It quite clearly states that you should leave the cluster size alone if your files are typically small.

Re: Why is Windows so slow?

#47
post #38
post #10

I don't know this poster, but I am pretty familiar with the problem he's encountering, as I am the person most responsible for the Chrome build for Linux. I (and others) have put a lot of effort into making the Linux Chrome build fast. Some examples are multiple new implementations of the build system ( http://neugierig.org/software/chromium/notes/2011/02/ninja.h... ), experimentation with the gold linker (e.g. measu…

You can build almost any Visual Studio project with out using visual studio at all. Visual Studio project files are also MSBuild files. I've setup lots of build machines sans Visual Studio, projects build just fine with out it. MSBuild does suck in that there is little implicit parallelism, but you can hack around it. I have a feeling that the Windows build slowness probably comes from that lack of parallelism in msb…

I agree about your msbuild points, in fact I don't think it's that bad of a build system and just under-utilized (hidden, for the most part/most users, behind the shiny GUI tools).

Access times: According to the comments on that blog entry (and according to all search hits that I could find, see for example [1]) atime is already disabled by default on Windows 7, at least for new/clean installs.

1: http://superuser.com/questions/200126/are-there-any-negative...

Re: Why is Windows so slow?

#48
I'm not sure if it is related, but the fact is that file system operation on windows are much slower that on Linux. I remembering that copying large ISO image from one windows partition to another windows partition using Total Commander under Wine on Linux was faster that doing it directly on Windows.

I also remember that I was able to create file copy utility in assembly as a homework assignment that was couple times faster than windows/dos copy command.

The only two reasons I can think of that explain this are: 1 - noone cares about windows fileystem performance. 2 - someone decided that it shouldn't be too fast.

Re: Why is Windows so slow?

#49
post #36

I suspect it has something to do with NTFS updating access times by default. So every time you do anything with a file, it gets its access time updated (not modification time, access time). I don't have windows to test on, but you could try the suggestions [1][2] below. [1] http://msdn.microsoft.com/en-us/library/ms940846(v=winembedd... [2] http://oreilly.com/pub/a/windows/2005/02/08/NTFS_Hacks.html (#8)

As posted elsewhere and as someone pointed out in the very comments of the article: That doesn't seem to be the case for Windows 7 anymore.

Re: Why is Windows so slow?

#50
post #36

I suspect it has something to do with NTFS updating access times by default. So every time you do anything with a file, it gets its access time updated (not modification time, access time). I don't have windows to test on, but you could try the suggestions [1][2] below. [1] http://msdn.microsoft.com/en-us/library/ms940846(v=winembedd... [2] http://oreilly.com/pub/a/windows/2005/02/08/NTFS_Hacks.html (#8)

But most Linux distros do this by default as well. You have to mount with noatime to get rid of it.

Linux has defaulted to relatime since 2009.
Post reply on HN