Live data from Hacker News

Why is Windows so slow?

games.greggman.com

91–100 of 159 posts

Re: Why is Windows so slow?

#91
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.

Which version of Windows? In my experience certain things will freeze up explorer XP/Server2k3 effectively indefinitely while on Vista/7/Server2k8 there is a progress meter and everything is stable.

Re: Why is Windows so slow?

#92
post #41
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…

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.

NTFS uses run lists (comparable to extends in ext4) so you would only have more metadata if your drive gets fragmented. (Which I hope for the sake of comparability is not the case here)

Re: Why is Windows so slow?

#93
1) Windows FS operations are slower than Linux in general but when you add 'Realtime' Antivirus on top it gets worse.

2) Linux forks significantly faster than anything else I know. For something like Chromium the compiler is forked bazillion times and so is the linker and nmake and so on so forth.

3) Linux, the kernel, is heavily optimized for building stuff as that's what the kernel developers do day in and day out - there are threads on LKML that I can't be bothered to dig out right now but lot of effort goes in to optimizing for kernel build workload - may be that helps.

3) Linker - stock one is slower and did not do the more costly optimizations until now so it might be faster because of doing lesser than the MS linker that does incremental linking, WPO and what not. Gold is even faster and I may be wrong but I don't think it does what the MS linker does either.

4) Layers - Don't know if Cygwin tools are involved but they add their own slowness.

Re: Why is Windows so slow?

#94
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…

Firefox uses VS2005 for builds in order to support XP pre-SP3.

Re: Why is Windows so slow?

#95

Earlier quoted context omitted.

Please show me something to back this nonsense up.

How about you back up calling it nonsense?

We've done compiler tests between VC express 2010 and GCC (Mingw gcc 4.6.x branch) at work with GCC beating VC express at '-O3 -ffast-math -march=corei7' vs '/O2 /arch:SSE2' for our code on Intel Core i7 nehalem. GCC even beat ICC on certain tests on that same Intel hardware.

What we weren't able to compare between the compilers was link-time optimization and profile-guided optimization since Microsoft crippled VC express by removing these optimizations.

So when someone makes claims that 'VC++ generates significantly better code than GCC' I want to see something backing that up. Had I made a blanket statement that 'GCC generates significantly better code than VC++' someone would call me on backing up that aswell, and rightly so.

Re: Why is Windows so slow?

#97
Don't forget forking.

To benchmark the maximum shell script performance (in terms of calls to other tools per second), try this micro-benchmark:

    while true; do date; done | uniq -c
Unix shells under Windows (with cygwin, etc.) run about 25 times slower than OS X.

Re: Why is Windows so slow?

#98
post #88

Earlier quoted context omitted.

There's a 64-bit version of the MSVC toolchain and MSBuild, so if you build outside of Visual Studio you won't be so constrained. This is how we do our builds here at work (a mix of C# and C++). We still edit code in VS, but local builds and continuous integration are done entirely using MSBuild. As of VS2010, C++ project files are MSBuild projects, and no longer need to use VCBuild.exe.

I didn't know about the 64-bit toolchain, where can you get it?

[deleted]

Re: Why is Windows so slow?

#99
Overall, the author's argument is somewhat dependent on a premise that Windows 7 should be optimized for edge cases such as compiling code written for multiplatform implementation (e.g. Chrome) rather than using the managed code model around which Microsoft's development of Windows has been centered for many years.

If one were optimizing Windows performance, none of the specific areas used as examples would receive much attention given user demographics. What percentage of Windows users use the command line, much less compile C programs, never mind using "cmd" shells to do so?

Windows command line gurus will be using Powershell these days, not the legacy encumbered "cmd" - elsewise they are not gurus.

Re: Why is Windows so slow?

#100
post #88

NTFS is a slower file system, that's probably the main reason why. Also console I/O is much better on Linux than Windows. Our software builds everyday on FreeBSD, Linux and Windows on servers that are identical. The windows build takes 14 minutes. The FreeBSD and Linux build take 10 minutes (they run at almost identical speed). Check out is more than twice slower on Windows (we use git). Debug build time is comparabl…

There's a 64-bit version of the MSVC toolchain and MSBuild, so if you build outside of Visual Studio you won't be so constrained. This is how we do our builds here at work (a mix of C# and C++). We still edit code in VS, but local builds and continuous integration are done entirely using MSBuild. As of VS2010, C++ project files are MSBuild projects, and no longer need to use VCBuild.exe.

I don't think this is true, at least for the C++ compiler. There's a 32-bit version producing 32-bit code, a 32-bit version producing 64-bit code and a 64-bit version producing 64-bit code.

Disclaimer: I work at Microsoft, but this is my hazy recollection rather than some kind of informed statement.

Post reply on HN