Why is Windows so slow?

Post by viraptor » Mon, Dec 19, 2011, 12:10 PM UTC

TwoBit wrote: post #55

vog wrote: post #44

Earlier quoted context omitted.

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…

VC++ generates significantly better code than GCC. Enough so that performance-minded projects usually wouldn't consider MinGW/GCC for Windows code.

Post by rplnt » Mon, Dec 19, 2011, 12:19 PM UTC

barrkel wrote: post #35

hristov wrote: 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.

Post by yread » Mon, Dec 19, 2011, 12:33 PM UTC

biot wrote: post #46

yread wrote: post #27

Earlier quoted context omitted.

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.

Post by viraptor » Mon, Dec 19, 2011, 1:11 PM UTC

dagw wrote: post #86

viraptor wrote: post #81

Earlier quoted context omitted.

Does it matter during development though? You could always develop on GNU toolchain and then make a final build in VC once the feature code is complete.

Only if you are careful to only use the subset of the C++ spec supported by both compilers and avoid all gcc specific features.

Post by markokocic » Mon, Dec 19, 2011, 1:26 PM UTC

m_for_monkey wrote: post #61

markokocic wrote: post #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 time…

In Total Commander you can configure the buffer sizes used while copying. Maybe in your homework you chose the right buffer size too (and, of course, asm is fast, but hard to write, I'm sure you didn't bother too much with error checking and other "small" problems). Moreover, the optimal buffer size is different for small and large files, maybe Windows is not optimized for large size like a DVD image.