Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why is Windows so slow?

games.greggman.com

Post reply on HN
Print view View original

121–130 of 159 posts

Re: Why is Windows so slow?

#121

Post by groby_b »

evmar wrote: 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…

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)

Re: Why is Windows so slow?

#122

Post by groby_b »

portman wrote: post #113

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: %t…

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

Re: Why is Windows so slow?

#123

Post by groby_b »

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.

Which might be a good choice for working on Chromium anyways, what with it being cross-platform :)

(Granted, there might be windows-specific stuff. I haven't checked the windows code)

Re: Why is Windows so slow?

#124

Post by ajross »

coverband wrote: post #115
portman wrote: post #113

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: %t…

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.

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.

Re: Why is Windows so slow?

#125

Post by koenigdavidmj »

Mavrik wrote: post #118
jcromartie wrote: post #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.

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.

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

Re: Why is Windows so slow?

#126

Post by shadowfox »

hkarthik wrote: post #103
_3u10 wrote: post #38

Earlier quoted context omitted.

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…

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 c…

> 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

You don't necessarily have to use VS to develop on windows. Mingw works quite well for a lot of cross-platform things and it is gcc and works with gnu make.

My experience with porting OSS between Windows and Linux (both ways) has been that very few developers take the time out to encapsulate OS specific routines in a way that allows easy(ier) porting. You end up having to #ifdef a bunch of stuff in order to avoid a full rewrite.

This is not a claim that porting is trivial. You do run in to subtle and not-so-subtle issues anyway. But careful design can help a lot. Then again this requires that you start out with portability in mind.

Re: Why is Windows so slow?

#127

Post by jlarocco »

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.

They would be doing this anyway.

Re: Why is Windows so slow?

#128

Post by r00fus »

WayneDB wrote: post #102

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…

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

Re: Why is Windows so slow?

#129

Post by Lagged2Death »

frooxie wrote: post #120

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?

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.

Re: Why is Windows so slow?

#130

Post by barrkel »

83457 wrote: post #91
barrkel wrote: post #35

Earlier quoted context omitted.

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.

Windows 7 x64. But I am talking about the command-line, not the UI. The UI controls (whether in Explorer or in other apps) generally don't react well to non-human sized input.
Post reply on HN