I do work on large projects in the multi-hour range for a full rebuild, and the compile time is still pretty much the lowest priority in selecting a compiler. All things being equal, of course I'd like to have the fastest compiles possible. But more important than that is that I can write the code I need to write without dodging compiler bugs / shortcomings all day, and deliver a binary which is optimized well for the target.
You can adapt to slow compiles. Breaking the project up into libraries, for example. You can't readily adjust to other compiler problems.
Pfft. Fusion reactor, so passe. It's just a classic steam engine with a hotter fire, after all.
We want something truly revolutionary! Something, I say!
The restriction is for Windows RT, so isn't relevant to the discussion about Windows 8.
It means you're actively wondering how they're counting you as an active G+ user after you only logged into YouTube.
I'm pretty sure the author wasn't actually referring to queued rendered frames, but rather "headroom" of rendering performance before the FPS dips to perceptible choppiness in times of high loading.
Windows 7 can still be targeted by a IE bug that's been in place since IE6. Safari doesn't have zero day bugs *that* old
How would you know? Zero-day means a non-public exploit.
Safari was released in early 2003.
Internet Explorer 6 was released in August 2001.
So the unfixed Internet Explorer bugs have been around quite a bit longer than Safari has. So Safari is unlikely have any bugs older than this IE bug, zero-day or otherwise.
(OK, there could be crusty KHTML era bugs left in the Safari code-base, but there's not much of that code left untouched)
I got frustrated with FF 3.5.2's occasional pauses while i was trying to smoothly and rapidly scroll through a long page of images and links (ve3d) to embedded videos yesterday. The main Slashdot page showed some of the same behavior. I'd grab the scroll bar, pull down, and the framerate of the scroll would stutter and occasionally lag to the extent that it skipped a whole screen in catching up. I decided that I'd do a qualitative benchmark on those two pages on all the major browsers, then find a way to get good adblocking on whichever I picked. This was in Windows 7 with a c2d at 2.6 ghz, 4 gigs of ram, and a 4870.
First I tried IE8, since it was already installed. Surprisingly, it wasn't worse than FF. It wasn't noticeably faster either. A tie goes to the status quo, so I waved goodbye to Trident and moved on. Then I tried Chrome, expecting to encounter my winner. Instead, the problems were vastly worse. Javescript benchmarks showed me much higher scores with Webkit, as expected, but in terms of HTML rendering it was much, much slower. The scroll bar itself noticeably lagged behind my cursor, sometimes to the extent that my cursor exited the bar until I slowed down to let it catch up. The pauses and hickups on the screen during scrolling went from being annoying to agonizing. I probably saw 2-5 fewer frames while scrolling than in FF or IE. Amazing, but true. I hoped that Google simply had a bad Webkit implementation, but sadly, Safari showed the same performance. I removed Chrome (easily) and Safari (less easily, since it installed two or three other Apple things that didn't go away during my Safari uninstall) and moved to my last option.
I installed Opera and ran the same test. I was blown away by how smooth the scrolling was. Loading those pages from cache also matched FF and went a little faster than Chrome/Safari (I didn't check IE). I hadn't expected much from Opera, but the new version (10) is, for me, the fastest browser in Windows. In the grand scheme of things, FF and IE are pretty fast, too, but even when I turned adblocking back on in FF it was still slower than Opera. I never really liked Opera in the past, but I'm going to use it as my main browser for awhile to see how it goes.
Speaking of which, is there an auto-updating adblocker plugin for Opera?
The confusion of a staff member is measured by the length of his memos. -- New York Times, Jan. 20, 1981