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…
Why is Windows so slow?
41–50 of 159 posts
Re: Why is Windows so slow?
#42Interestingly 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.
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?
#43Re: Why is Windows so slow?
#44I 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…
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?
#45Interestingly 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…
Re: Why is Windows so slow?
#46Here 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…
Re: Why is Windows so slow?
#47I 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…
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?
#48I 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?
#49I 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)
Re: Why is Windows so slow?
#50I 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.