Why is Windows so slow?

http://games.greggman.com/game/why-is-windows-so-slow/

by kristianp • 15 years ago

337 153 15 years ago

games.greggman.com

etfb2• 15 years ago

Someone posted the question on StackOverflow and it got closed as "not constructive". Is there a way to browse the "not constructive" questions on SO? They seem to be all the best ones.

Mithrandir• 15 years ago

Ref: http://stackoverflow.com/questions/6916011/how-do-i-get-wind... (By the author)

Top Answer:

Unless a hardcore windows systems hacker comes along, you're not going to get more than partisan comments (which I won't do) and speculation (which is what I'm going to try).

1. File system - You should try the same operations (including the dir) on the same filesystem. I came across this which benchmarks a few filesystems for various parameters.

2. Caching. I one tried to run a compilation on Linux on a ramdisk and found that it was slower than running it on disk thanks to the way the kernel takes care of caching. This is a solid selling point for Linux and might be the reason why the performance is so different.

3. Bad dependency specifications on windows. Maybe the chromium dependency specifications for Windows are not as correct as for Linux. This might result in unnecessary compilations when you make a small change. You might be able to validate this using the same compiler toolchain on Windows.

buster2• 15 years ago

Why should he run the ls command on ntfs rather then a native file system? In all it was a "windows vs linux" test and not a fileystem test. Testing the same filesystem wouldn't make sense here

bitops• 15 years ago

Well, this article seems to be asking "why is the Windows file system so slow?" and generally complaining. A better name for the article might be "Windows FS performance sucks" or similarly polemical title.

There are parts of Windows that are implemented just the same as Linux, and parts that are faster. Some parts are slower, notably the file system. But there's more to Windows than just the file system.

So, I'd say that's why it's not constructive.

alextingle2• 15 years ago

Well that's the question isn't it? Is it just the filesystem, or is the speed of CL.EXE an issue too? What about the VS build system?

It sounds like you simply don't know enough about the issue to judge whether it's constructive.

thirsteh• 15 years ago

Interesting. I wonder how many "Linux-bashing threads" (that contained valid questions which made perfect sense) were closed as not constructive.

darklajid3• 15 years ago

No need to invent a new conspiracy - closing and reopening happens regularly and for a lot of reasons/subjects.

Just - add a vote to reopen it, if you feel that the question is relevant. I just did.

6ren2• 15 years ago

http://data.stackexchange.com/

It's an online SQL tool for analyzing the stackoverflow data dump (last update was Sept 2011; they're quarterly http://blog.stackoverflow.com/category/cc-wiki-dump/). It's very cool, but curiously hard to find. There's a "[data-explorer]" tag at meta.stackoverflow: http://meta.stackoverflow.com/questions/tagged/data-explorer

The PostHistory table probably records why posts were closed.

6ren2• 15 years ago

And here's your answer: top closed SO questions! http://data.stackexchange.com/stackoverflow/s/2305/top-close... (link includes hyperlinks to all the questions)

  score id post
  1416 1711 What is the single most influential book every programmer should read?
  1409 9033 Hidden Features of C#?
  1181 101268 Hidden features of Python
  979 1995113 Strangest language feature
  736 500607 What are the lesser known but cool data structures?
  708 6163683 Cycles in family tree software
  671 315911 Git for beginners: The definitive practical guide
  653 662956 Most useful free .NET libraries?
  597 891643 Twitter image encoding challenge
  583 83073 Why not use tables for layout in HTML?
  579 2349378 New programming jargon you coined?
  549 621884 Database development mistakes made by application developers
  537 1218390 What is your most productive shortcut with Vim?
  532 309300 What makes PHP a good language?
  505 1133581 Is 23,148,855,308,184,500 a magic number, or sheer chance?
  488 114342 What are Code Smells? What is the best way to correct them?
  481 432922 Significant new inventions in computing since 1980
  479 3550556 I've found my software as cracked download on Internet, what to do?
  479 380819 Common programming mistakes for .NET developers to avoid?
  473 182630 jQuery Tips and Tricks

The query (also at http://data.stackexchange.com/stackoverflow/s/2305/top-close... ) - have a play.

  SELECT top 20
    p.score, p.id, p.id as [Post Link]
  FROM Posthistory h
    INNER JOIN PosthistoryTypes t ON h.posthistorytypeid = t.id
    INNER JOIN Posts p ON h.postid = p.id
  WHERE
    t.name = 'Post Closed'
  GROUP BY p.score, p.id
  ORDER BY p.score DESC

manojlds• 15 years ago

closed questions are still there. Only the deleted ones are gone ( but accessible to those with more than 10k reputation)

johnx123-up• 15 years ago

FWIW, try disabling your AV

qdog• 15 years ago

This.

And anything else you can find that registers with the kernel for file system calls. Logging mechanisms, etc. Anything the kernel has to talk to about file i/o is going to slow it down.

einhverfr• 15 years ago

I have found Windows a bit slower but never to the extent the author suggests. But then I have generally tested on clean systems without antivirus. So I suspect that this is a huge factor, esp. because it intercepts all FS calls and checks them. That's really not what you want when compiling code.

ervvynlwwe• 15 years ago

The author doesn't mention whether he is using cygwin git, or msys git. msys is faster. But even with msys, UAC virtualization is a common cause of slowness with git: http://stackoverflow.com/questions/2835775/msysgit-bash-is-h...

More details here: http://code.google.com/p/msysgit/issues/detail?id=320

obtu4• 15 years ago

Sure, Cygwin does a bit of extra wrapping. The official site and just about anybody link to msysgit, however.

false• 15 years ago

Git under cygwin is so painfully slow, and gets exponentially slower as number of tracked files grow. Even SSD can't fully smooth out the difference :(

evmar3• 15 years ago

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. measuring and adjusting the still off-by-default thread flags https://groups.google.com/a/chromium.org/group/chromium-dev/... ) as well as digging into bugs in it, and other underdocumented things like 'thin' ar archives.

But it's also true that people who are more of Windows wizards than I am a Linux apprentice have worked on Chrome's Windows build. If you asked me the original question, I'd say the underlying problem is that on Windows all you have is what Microsoft gives you and you can't typically do better than that. For example, migrating the Chrome build off of Visual Studio would be a large undertaking, large enough that it's rarely considered. (Another way of phrasing this is it's the IDE problem: you get all of the IDE or you get nothing.)

When addressing the poor Windows performance people first bought SSDs, something that never even occurred to me ("your system has enough RAM that the kernel cache of the file system should be in memory anyway!"). But for whatever reason on the Linux side some Googlers saw it fit to rewrite the Linux linker to make it twice as fast (this effort predated Chrome), and all Linux developers now get to benefit from that. Perhaps the difference is that when people write awesome tools for Windows or Mac they try to sell them rather than give them away.

Including new versions of Visual Studio, for that matter. I know that Chrome (and Firefox) use older versions of the Visual Studio suite (for technical reasons I don't quite understand, though I know people on the Chrome side have talked with Microsoft about the problems we've had with newer versions), and perhaps newer versions are better in some of these metrics.

But with all of that said, as best as I can tell Windows really is just really slow for file system operations, which especially kills file-system-heavy operations like recursive directory listings and git, even when you turn off all the AV crap. I don't know why; every time I look deeply into Windows I get more afraid ( http://neugierig.org/software/chromium/notes/2011/08/windows... ).

Adaptive• 15 years ago

Chrome on Linux is awesome. At some point in the past year I stopped having to use command line options to keep it in memory as it defaults to that. Brilliant and slick, I love it. Chrome's performance and syncing is the reason I was able to transition almost entirely over to Linux from Mac this year with very little workflow disruption.

maximilianburke• 15 years ago

When developing on Windows it pays significant dividends to manage your include files. There are a number of files provided as part of Visual Studio and/or the Windows SDK that bring in a tremendous amount of large other files.

Unlike with Linux it's quite difficult to perform piecemeal inclusion of system header files because of the years of accumulated dependencies that exist. If you want to use the OS APIs for opening files, or creating/using critical sections, or managing pipes, you will either find yourself forward declaring everything under the moon or including Windows.h which alone, even with symbols like VC_EXTRALEAN and WIN32_LEAN_AND_MEAN, will noticeably impact your build time.

DirectX header files are similarly massive too. Even header files that seem relatively benign (the Dinkumware STL <iterator> file that MS uses, for example) end up bringing in a ton of code. Try this -- create a file that contains only:

    #include <vector>

Preprocess it with GCC (g++ -E foo.cpp -o foo.i) and MSVC (cl -P foo.cpp) and compare the results -- the MSVC 2010 version is seven times the size of the GCC 4.6 (Ubuntu 11.10) version!

ArbitraryLimits• 15 years ago

I came here to say this. Anytime Unix people complain about slow builds "on Windows," 9 times out of 10 it's because they're ignoring precompiled headers. The other 1 time out of 10 it's because they're using configure scripts under cygwin and finding out how expenseive cygwin's implementation of fork() can be.

fleitz• 15 years ago

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 msbuild.

As for directory listings it may help to turn off atime, and if it's a laptop enable write caching to main memory. I'm not quite sure why Windows file system calls are so slow, I do know that NTFS supports a lot of neat features that are lacking on ext file systems, like auditing.

As for the bug mentioned, it's perfectly simple to load the wrong version of libc on linux, or hook kernel calls the wrong way. People hook calls on Windows because the kernel is not modifiable, and has a strict ABI, it's a disadvantage if you want to modify the behavior of Win32 / Kernel functions, but a huge advantage if you want to write say, graphics drivers and have them work after a system update.

Microsoft doesn't recommend hooking Win32 calls for the exact reasons outlined in the bug, if you do it wrong you screw stuff up, on the other hand, rubyists seem to love the idea that you can change what a function does at anytime. I think they call it 'dynamic programming'. I can make lots of things crash on Linux by patching ld.config so that a malware version of libc is loaded. I'd hardly blame the design of Windows when malware has been installed.

Every OS/Kernel involves design trade offs, not every trade off will be productive given a specific use case.

darklajid3• 15 years ago

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

hkarthik• 15 years ago

Regarding MSBuild, the biggest problem I had with it is that if you built projects with Visual Studio, using most of the standard tooling for adding references and dependencies, you'd often be left with a project that built fine with Visual Studio, but had errors with MSBuild.

The reverse, incidentally, was usually okay. If you could build it with MSBuild, it usually worked in Visual Studio unless you used a lot of custom tasks to move files around.

I personally believe the fact that Visual Studio is all but required to build on Windows is one of the single most common reasons you don't see much OSS that is Windows friendly aside from those that are Java based.

colton36• 15 years ago

> MSBuild does suck in that there is little implicit parallelism

/m enables parallelism on the .NET side. Perhaps the same thing exists for the native compiler?

vog• 15 years ago

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/)

TwoBit2• 15 years ago

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

forrestthewoods• 15 years ago

tldr; no one at Google uses windows, a lot of time was spent optimizing the linux build, zero time was spent optimizing the windows builds.

statictype• 15 years ago

Perhaps the difference is that when people write awesome tools for Windows or Mac they try to sell them rather than give them away.

Well, if that was true, then you could just buy the better tool and use it, right? I suspect they don't exist because

a) On Linux, you have the existing linker to build your better one on. On Windows, you'd have to write your own from scratch making it less appealing for anyone (only people who'd buy it were those running huge projects like Chrome)

b) What you said about the file system itself just being plain slow.

PS: (Long time follower of evan_tech - nice to see you popup around here :) )

celticjames• 15 years ago

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

jonhendry2• 15 years ago

"Perhaps the difference is that when people write awesome tools for Windows or Mac they try to sell them rather than give them away."

Apple's switching from gcc to clang/llvm, and doing a lot of work on the latter, which is open source.

groby_b4• 15 years ago

A large part of Windows slowness is NTFS, as you allude to in your last sentence. There are a myriad ways to slow the damn thing down, and none to make it significantly faster.

There's also the issue that it seems to slow down exponentially with directory size. In short, worst FS for building large software.

As for the OP's build time complaint about XCode - don't do that. Use the make build instead. Not only does XCode take forever to determine if it needs to build anything at all, it caches dependency computations. So if you do modifications outside of XCode, too, welcome to a world of pain :) (I know evmar knows, but for the OP: Use GYP_GENERATORS=make && gclient runhooks to generate makefiles for Chromium on OSX)

greggman• 15 years ago

the make build didn't exist at the time I posted that AFAIK. The make build is oodles faster than the xcode build and I use it now of course but it's still the slowest platform to build chromium on by a long margin.

malkia2• 15 years ago

On Windows, SysInternals's RamMap is your friend. Also the System Internals book (#5 I think).

Every file on Windows keeps ~1024 bytes of info in the file cache. The more the files the more cache would be used.

Recent finding, that sped up our systems from 15->3sec on 300,000+ files filestamp check was to move from _stat to GetFileAttributesEx.

One would not think of doing such things, after all the C api is nice, open, access, bread, _stat are almost all there, but some of these functions do a lot of CPU intensive work (and one is not aware, until just a little bit of disassembly is done).

For example _stat does lots of divisions, dozen of kernel calls, strcmp, strchr, and few other things. If you have Visual Studio (or even Express) the CRT source code is included for one to see.

access() for example is relatively "fast", in terms that there is just mutex (I think, I'm on OSX right now), and then calling GetFileAttributes.

And back to RamMap - it's very useful in the sense that it shows you which files are in the cache, and what portion of them, also very useful that it can flush the cache, so one can run several tests, and optimize for hot-cache and cold-cache situations.

Few months ago, I came up with a scheme, borrowing idea from mozilla - where they would just pre-read certain DLLs that would eventually came up to be loaded (in a second thread).

I did the same for one our tools, the tool is single threaded, reads, operates, then writes. And it usually reads 10x more than it writes. So while the process operation was able to get multi-threaded through OpenMP, reading was not, so instead I had a list of what to read ahead, in a second thread, so that when it comes to the first thread, and it wanted to read, it was taking it from the cache. If the pre-fetcher was behind, it was skipping ahead. There was not even need to keep the contents in memory, just enough to read, and that's it.

For some other tool, where reading patterns cannot be found easily (deep-tree hierarchy) I've made something else instead - saving in a binary file what was read before for the given set of command-line arguments (filtering some). Later that was reused. It cut down on certain operations 25-50%.

One lesson I've learned though is to let the I/O do it's job from one thread... Unless everyone has some proper OS, with some proper drivers, with some proper HW, with....

Tim Bradshaws' widefinder, and widefinder2 competition had also good information. The guy that win it, has on his site some good analysis of multi-threaded I/O (can't find the site now),... But the analysis was basically that it's too erratic - sometimes you get speedups, but sometimes you get slowdowns (especially with writes).

evmar3• 15 years ago

Thanks for the GetFileAttributesEx tip -- https://github.com/martine/ninja/commit/93c78361e30e33f950ee...

iradik2• 15 years ago

Hmm.. I've had an opposite experience on an atom netbook. Tried Windows Vista and Ubuntu on a netbook. The Windows netbook worked great while Ubuntu regularly would crash. Ubuntu on the netbook was unusable. Now probably I did something wrong? But just installed the latest version with default settings. Anyway I returned the netbook.

alextingle2• 15 years ago

Were you running compiles on it??

iradik2• 15 years ago

No I was running a web browser and a chat program.

reledi• 15 years ago

The author has an issue with speed, not stability.

niyazpk• 15 years ago

Here is a link from the comments:

NTFS Performance Hacks - http://oreilly.com/pub/a/windows/2005/02/08/NTFS_Hacks.html

yread2• 15 years ago

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 drives and will allow files to open slightly faster.

is wrong. When you increase cluster size you will definitely not "reduce the amount of space you are wasting". 100B file will still occupy the whole 16KB ( so you will waste 15.9KB on it instead of 3.9KB with 4KB clusters.

Also I would be very careful with taking advice like that from an article which is 6 years old (before introduction of Win7 or XP SP3!)

maaku• 15 years ago

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.

biot2• 15 years ago

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.

rbanffy2• 15 years ago

I haven't used Windows as my primary OS for almost a decade and haven't even booted it on bare metal for the past couple years, so my guesses must be taken with a grain of salt. I always found directory fragmentation (much more than file fragmentation) to be a huge performance problem on Windows. If increasing cluster size effectively reduces directory fragmentation, your life under Windows will be much better.

jstclair3• 15 years ago

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.

vacri2• 15 years ago

There is indeed marked differences between unix terminals - xterm is blazingly fast. Do the same test the author did with xterm and with another terminal and you'll see significant differences. cmd may just be a slow terminal masking actual windows speed.

vacri2• 15 years ago

I will never, ever understand the downmodding on this site. There is no particular opinion in this statement - it's an informative statement that the speed of your terminal can matter. I find it strange that on a site claiming to be for hackers that a fairly opinion-free comment on terminal speed differences gets downmodded.

It's hard to keep a thick skin about having your voice diminished when even your informative, unopinionated stuff gets shut down.

shabble2• 15 years ago

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.

jstclair3• 15 years ago

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.

perlgeek• 15 years ago

Huh? He redirected the output to a file, so terminal speed doesn't really factor in here.

baudehlo• 15 years ago

It might be, actually, since dir is a command built into cmd.exe on Windows, not a separate .exe that gets run. It may be smarter to use "ls" from cygwin for the test.

hristov2• 15 years ago

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 believe that is probably the problem with Windows in general. Perhaps there are a lot of bad algorithms hidden in the enormous and incredibly complex Windows code base and they are not getting fixed because Microsoft has not devoted resources to fixing them.

Linux on the other hand benefits from the "many eyes" phenomenon of open source and when anyone smart enough notices slowness in Linux they can simply look in the code and find and remove any obviously slow algorithms. I am not sure all open source software benefits from this but if any open source software does, it must certainly be Linux as it is one of the most widely used and discussed pieces of OS software.

Now this is total guesswork on my part but it seems the most logical conclusion. And by the way, I am dual booting Windows and Linux and keep noticing all kinds weird slowness in Windows. Windows keeps writing to disk all the time even though my 6 GB of RAM should be sufficient, while in Linux I barely hear the sound of the hard drive.

barrkel7• 15 years ago

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.

hristov2• 15 years ago

I think the fact that is hot in cache may have influenced things here.

prewett3• 15 years ago

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.

obtu4• 15 years ago

For all you know you're seeing the HDD cache and not any kind of filesystem caching. evmar mentions SSD making a difference for workloads that should fit in RAM, which means HDD caching also would, for a very modest workload.

rplnt• 15 years ago

I think the recursive search is the thing that is broken.

83457• 15 years ago

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.

prewett3• 15 years ago

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.

jstclair3• 15 years ago

You could try this (from an elevated command-prompt), but the general consensus is that it has a small (if any) effect:

reg add "HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management" -v DisablePagingExecutive -d 0x0 -t REG_DWORD -f

Disable it with: reg add "HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management" -v DisablePagingExecutive -d 0x1 -t REG_DWORD -f

More discussion here: http://serverfault.com/questions/12150/does-the-disablepagin...

The easiest way (if you have enough memory) is just disable the paging file.

fauigerzigerk2• 15 years ago

I just wish the "many eyes" phenomenon worked equally well for device drivers.

praptak• 15 years ago

Unfortunately most of the drivers are in the long tail of unpopular devices. This results in greatly reducing the average number of eyes per driver.

This has a double effect: there are less developers who can attempt to fix problems with a driver and second, the incentive seems smaller - make general I/O 0.5% faster and you're a hero of the public, fix a critical problem in an unpopular device driver and maybe 1 person notices.

jonhendry2• 15 years ago

"Linux on the other hand benefits from the "many eyes" phenomenon of open source and when anyone smart enough notices slowness in Linux they can simply look in the code and find and remove any obviously slow algorithms."

More like Linux benefits from "many budgets and priorities". If someone at Microsoft spots an obviously slow algorithm, they may not be allowed to fix it, rather than working on whatever they're supposed to be working on, which probably doesn't include "fixing shipped, mature code that pretty much works in most cases."

On the Linux side, someone can decide it's really freakin' important to them to fix a slow bit, and there's little risk of it being a career-limiting move.

barrkel7• 15 years ago

Probably a big reason for him seeing slowdowns in incremental builds with MSVC is because of link-time code generation. What seems to be link time is actually code generation time, and it's delayed because intra-procedural optimizations can be run. This kills off a lot of the benefit of incremental building - you're basically only saving parsing and type analysis - and redoing a lot of code generation work for every modification.

NTFS also fragments very badly when free space is fragmented. If you don't liberally use SetFilePointer / SetEndOfFile, it's very common to see large files created incrementally to have thousands, or tens of thousands, of fragments. Lookup (rather than listing) on massive directories can be fairly good though - btrees are used behind the scenes - presuming that the backing storage is not fragmented, again not a trivial assumption without continuously running a semi-decent defragmenter, like Diskeeper.

tankenmate• 15 years ago

The problem as I understand it is that Windows's file metadata cache is broken. I remember reading many years ago a posting by Linus about this but I can't find it at the moment.

According to this document (http://i-web.i.u-tokyo.ac.jp/edu/training/ss/lecture/new-doc...) it would appear that directory entries have one extra level of indirection and share space with the page cache and hence can be pathologically evicted if you read in a large number of files; compiling/reading lots of files for example.

On Linux however the directory entry cache is a separate entity and is less likely to be evicted under readahead memory pressure. Also it should be noted is that Linus has spent a largish amount of effort to make sure that the directory entry cache is fast. Linux's inode cache has similar resistance to page cache memory pressure. Obviously if you have real memory pressure from user pages then things will slow down considerably.

I suspect that if Windows implemented a similar system with file meta data cache that was separate from the rest of the page cache it would similarly speed up.

Edit: I should note, this probably wouldn't affect linking as much as it would affect git performance; git is heavily reliant on a speedy and reliable directory entry cache.

prewett3• 15 years ago

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)

shintoist• 15 years ago

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

kinetik• 15 years ago

Linux has defaulted to relatime since 2009.

wazoox• 15 years ago

In fact nowadays most (all?) linux filesystems use relatime as default, which carries most of the advantages of both atime and noatime. See http://kerneltrap.org/node/14148

I don't know if something similar exists under windows (I suppose it doesn't).

darklajid3• 15 years ago

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.

lloeki• 15 years ago

Mac OS X does appear to mount with atime but I happened to use this:

    $ cat /Library/LaunchDaemons/com.nullvision.noatime.plist    
    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" 
            "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
    <plist version="1.0">
        <dict>
            <key>Label</key>
            <string>com.nullvision.noatime</string>
            <key>ProgramArguments</key>
            <array>
                <string>mount</string>
                <string>-vuwo</string>
                <string>noatime</string>
                <string>/</string>
            </array>
            <key>RunAtLoad</key>
            <true/>
        </dict>
    </plist>

I don't know if there's anything like relatime.

RexRollman• 15 years ago

The updating of last access time has been disabled since the release of Windows Vista (although you can turn it back on):

http://blogs.technet.com/b/filecab/archive/2006/11/07/disabl...

tintin• 15 years ago

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).

markokocic2• 15 years ago

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.

m_for_monkey• 15 years ago

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.

markokocic2• 15 years ago

As for Total commander example, that was out of the box experience, without any tweaks. I just wanted to point out that even when using emulation layer to access Windows native filesystem type, Linux was significantly faster on file system operations.

As for my homework "copy" command, I know that it is not fully replacement to file copy windows command, but if copy operations takes >10min, all those checks and additional tasks shouldn't make IO bound operation take couple time longer than what some student implemented as homework.

shin_lao6• 15 years ago

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 comparable 5 minutes for Windows, 4 minutes 35 on Linux.

Release build time is almost 7 minutes on Windows and half that on Linux.

VS compiles more slowly than gcc but overall it's a better compiler. It handles static variables better and is not super demanding about typenames like gcc is. Also gcc is extremely demanding in terms of memory. gcc is a 64-bit executable, Visual Studio is still a 32-bit execuable. We hope Microsoft will fix that in Visual Studio 2011.

Its easier to parallelize gmake than Visual Studio, which also explains the better Linux build time. Visual Studio has got some weird "double level" mulithreading which is eventually less efficient than just running the make steps in parallel as you go through your make file.

However our tests run at comparable speed on Linux and Windows and the Windows builds the archive ten times faster than Linux.

obtu4• 15 years ago

What is this archive step you mention in passing, and what makes Linux slow at it?

shin_lao6• 15 years ago

I don't know why Linux is so slow at it, it's when we build the tgz containing all the binaries before uploading it to the distribution server.

omellet5• 15 years ago

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.

shin_lao6• 15 years ago

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

CurtHagenlocher3• 15 years ago

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.

vmmenon• 15 years ago

"Why is Windows so slow? I’m a fan of Windows, specifically Windows 7."

????

blinkingled• 15 years ago

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.

nikcub• 15 years ago

This is a comparison of file systems, not operating systems.

jcromartie• 15 years ago

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.

Mavrik• 15 years ago

Well, Unix shells under Windows don't even implement forking, so this test is kinda meaningless isn't it?

It's like racing cars where one of the cars has its wheels taken off.

koenigdavidmj• 15 years ago

Cygwin has fork. The problem is that Cygwin's fork has to copy the entire address space into the new process, whereas Linux uses copy-on-write to make forking much faster (you only need to copy the page tables).

brudgers• 15 years ago

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.

WayneDB2• 15 years ago

I run Windows 7 in Boot Camp every day and it easily outperforms OS X on the same exact hardware for most common tasks (browsing files, the web, starting up apps, etc).

The Windows desktop GUI system is more stable than anything else out there (meaning that it's not going to change drastically AND that it's a solid piece of software that just works) and it's as flexible as I need it to be, so that's why I stick with Windows. With virtual machines, WinSCP, Cygwin and other similar utilities, I have all the access to *nix that I need.

r00fus• 15 years ago

> The Windows desktop GUI system is more stable than anything else out there (meaning that it's not going to change drastically AND that it's a solid piece of software that just works)

So you assume that Windows8 metro-mode won't really catch on? Also comparing OSX to Windows over the past 10 years, it's Windows that has changed more drastically, so both future and past evidence to the contrary...

WayneDB2• 15 years ago

How has Windows changed more drastically than OS X since 2001? To me drastic means that something very basic has changed and/or compatibility has been lost. (Things like resizable windows, full screen apps, broken finder plugin compatibility, changes to expose, addition of mission control, etc.)

I don't assume, know or care to know anything about Windows Metro. It's not replacing the desktop system that I use.

idspispopd• 15 years ago

separate point:

while photoshop isn't on linux, there are plenty of replacements for that unless he's doing print work, which I don't think is the case, as photoshop isn't the beginning and end for print. (actually, TBH, photoshop is pretty shit for pixel work.)

Also maya is available for linux, autodesk just doesn't offer a free trial like they do with windows/mac os. (Including the 2012 edition.)

With no offence intended to the 3dsmax crew, as it has it's merits, but a sufficiently competent maya user won't find much use for 3dsmax.

chris_gogreen• 15 years ago

Hard drive swap file usage, my windows machines always have a huge swap file going, my Linux and OS X machines almost never do.

portman• 15 years ago

I'm disappointed HN! There is a lot of pontificating, but not much science here.

It takes all of 2 minutes to try this experiment yourself (plus ~8 minutes for the download).

1. Download chromium http://chromium-browser-source.commondatastorage.googleapis....

2. Unzip to a directory

3. Create this batch file in the src directory, I called mine "test.bat"

    echo start: %time% >> timing.txt
    dir /s > list.txt
    echo end: %time% >> timing

4. Run test.bat from a command prompt, twice.

Paste your output in this thread. Here is mine:

    start: 12:00:41.30 
    end: 12:00:41.94 
    start: 12:00:50.66 
    end: 12:00:51.31

First pass: 640ms; Second pass: 650ms

I can't replicate the OP's claim of 40000ms directory seek, even though I have WORSE hardware. Would be interested in other people's results. Like I said, it only takes 2 minutes.

coverband• 15 years ago

Unfortunate that this comment doesn't get enough attention in this thread... A single person's experience will always be subjective (even with the provided technical detail). If it's not consistently repeatable, it can only be used as an anectode.

ajross• 15 years ago

I'm not sure what your point is. The post you're replying to is no less anecdotal. Obviously there are complicated performance interactions afoot here. In the OP's opinion (and mine) Windows is littered with these kinds of booby traps. Things usually work fast ... until they don't, and you have to dig hard to figure out why.

For the most part, Linux just doesn't do that. Obviously there are performance bugs, but they get discussed and squashed pretty quickly, and the process is transparent. On the occasions I'm really having trouble, I can generally just google to find a discussion on the kernel list about the problem. On windows, we're all just stuck in this opaque cloud of odd behavior.

evmar3• 15 years ago

Wow, you are awesome for posting facts! I have often wondered if it was some systemic thing about the centrally-managed setups of Windows at Google that was making the Chrome build suck so much (such as some aggressive antivirus, as people often suggest in these situations). My recollection is that people run into the same slow build problems on non-Google-owned Windows computers, but perhaps that "slow" is a different slow than the OP's problem.

(For comparison, I have an older checkout on this Linux laptop. It's around 145ms to list, and it's 123k files. The original post mentions 350k files, which is a significantly different number. It makes me wonder if he's got something else busted, like "git gc" turned off, creating lots of git objects in the same directory producing some O(n^2) directory listing problem. But it could just as well be something like build outputs from multiple configurations.)

groby_b4• 15 years ago

Try 'fsutil disablelastaccess 0'. Not sure if that's the case for the OP, but lastaccess is horrible on performance.

Renaud• 15 years ago

I think you mean 'fsutil behavior set disablelastacces 1' to disable last file access update.

keithwarren• 15 years ago

Macbook Pro (i7) with Vertex 3 SSD running Win7x64

start: 16:53:40.21 end: 16:53:53.18

start: 16:53:56.27 end: 16:54:09.31

(windows shows 283,871 files)

peterwwillis• 15 years ago

I'm pretty sure the "dir" takes longer than "ls" because "dir /s c:\list.txt" sorts the entire c:\ drive before looking for "list.txt". "ls -R c:\list.txt" first checks if "list.txt" exists, and fails if it doesn't. Just take out the "list.txt" and run both commands again.

frooxie• 15 years ago

What I can't wrap my head around is the amazingly slow file search (I'm using Vista). Searching for a filename I know exists in a small directory (say, 100 files) often leads to Windows searching for several minutes and then NOT FINDING THE FILE. How can that happen when Windows is able to list the contents of the directory (including the file I'm looking for) instantly?

Lagged2Death• 15 years ago

I am also frustrated by the indexed searching in Windows. This should have been a brilliant signature feature, and it's just execrable.

If you look at the indexing options in the Vista control panel and click the "Advanced" button, you'll find a dialog box with a "File Types" tab. This horrible dialog may show you (it did for me) that some file types (i.e., filename extensions) are deliberately excluded from indexing. For some reason. You know, because you may not want to find certain things when you look for them. I guess.

You'll also find the world's worst interface for specifying what kinds of file should be indexed by content. But never mind.

If searching by filename and/or path is all you're after, check out Everything:

http://www.voidtools.com/

If you're not using Windows as an Administrator, (and you shouldn't be) Everything won't seem very polished. But it is terrifyingly fast, and it's baffling that Microsoft's built-in search is this bad if something like Everything is possible.

malkia2• 15 years ago

A possible faster way to read directories with one (okay, few at most kernel calls) is to use GetFileInformationByHandleEx.

Here is some example:

https://gist.github.com/1487388

Why is Windows so slow?

Related Stories