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

131–140 of 159 posts

Re: Why is Windows so slow?

#131

Post by barrkel »

ajross wrote: post #124
coverband wrote: post #115

Earlier quoted context omitted.

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…

If something is slow with respect to the OS, you can often break out procmon and examine the stacks of the poorly performing requests; or if something is stalled, you can do the same with procexp. With dbghelp configured correctly, you get symbol resolution in the OS libraries, so you can see what's going on. Worst comes to worst, you can step through the disassembly with a debugger, but it's not often required.

When I have problems with Linux, I tend to have to fall back to strace or an equivalent, and I find it harder to figure out what's going on. On Solaris, if I can find the right incantations to use with dtrace, I can see where the problems are, but it's easy to get information overload.

My point is, how opaque your perspective is depends on your familiarity with the system. I have less trouble diagnosing holdups on Windows than I do on other systems. That's because I've been doing it for a long time.

Re: Why is Windows so slow?

#132

Post by keithwarren »

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…

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)

Re: Why is Windows so slow?

#133

Post by smackfu »

darklajid wrote: post #51
thirsteh wrote: post #6

Earlier quoted context omitted.

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

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.

Plus stackexchange has so many different subsites, the odds are any given question is off topic for where it was posted nowadays.

Re: Why is Windows so slow?

#134

Post by ArbitraryLimits »

maximilianburke wrote: post #26
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…

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

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.

Re: Why is Windows so slow?

#135

Post by omellet »

shin_lao wrote: post #90
omellet wrote: 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?

It's an optional install package when you install Visual Studio.

Re: Why is Windows so slow?

#136

Post by omellet »

CurtHagenlocher wrote: post #100
omellet wrote: 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 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.

The %VSROOT%\VC\bin\amd64 is indeed a native x64 binary.

Re: Why is Windows so slow?

#137

Post by TwoBit »

viraptor wrote: post #81
TwoBit wrote: post #55

Earlier quoted context omitted.

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

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.

I actually don't understand the original poster's slowness with Windows. We use Perforce and VC++ .slns, sometimes with apps split into DLLs and get none of the slowness the poster talks about. Actually we get significantly better performance with this than under Unix with GCC. No-change or small change rebuilds take a few seconds, with the time being dominated by the link and proportional to the link size.

Re: Why is Windows so slow?

#138

Post by mdda »

ConceptJunkie wrote: post #114
fauigerzigerk wrote: post #74

Earlier quoted context omitted.

Exactly. I'm afraid this isn't a solvable problem. Device makers must be responsible for device drivers, open source or not.

Generally, they are. They get their Windows compatibility certification and everything. Oh, wait, you mean for Linux? Good luck with that. The sad thing is that either providing drivers for Linux or providing detailed enough specs that drivers can be written by the OSS community offers little for no payback for the effort. As a Linux user, I feel lucky that any hardware manufacturers even acknowledge people might be…

That's what they used to say about IE vs the open source community. But somehow, programmers' nature finds a way...

Re: Why is Windows so slow?

#139

Post by CurtHagenlocher »

omellet wrote: post #136
CurtHagenlocher wrote: post #100

Earlier quoted context omitted.

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.

The %VSROOT%\VC\bin\amd64 is indeed a native x64 binary.

Yes, but it can only produce x64 code; it can't produce x86 code. Mind you, I'd love to be wrong about that...

Re: Why is Windows so slow?

#140

Post by vacri »

vacri wrote: post #19
jstclair wrote: post #17

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.

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.

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.

Post reply on HN