Then the Chrome / Windows machine, which no one tried to attack (one person found an exploitable hole, but sold it to Google for $1,337 instead of entering it into the contest).
You're confusing Chrome and Android: http://jon.oberheide.org/blog/2011/03/07/how-i-almost-won-pwn2own-via-xss/
I talked to the guys who won yesterday, and one of the Team Anon guys who was originally signed up for Chrome. Some of them said their WebKit bugs affected Chrome, but no one had figured out how to break the Chrome sandbox. So, they just withdrew their names rather than waste everyone's time with an exploit they knew wouldn't work.
You're joking, right? Apple is historically months behind in patching publicly disclosed vulnerabilities in core libraries they share with other Unix-like systems (Samba and Java are two key examples). Overall code robustness is abysmal in any Apple product I've assessed--they fall over with trivial fuzzing or a few hours of analysis. They're an absolute pain in the ass to deal with when trying to resolve a responsibly reported vulnerability: they often don't seem to have qualified people triaging inbound reports, and when they do finally acknowledge the correct severity of a reported issue it can take years before they finally push out a fix. And to top it all off, their core security counter-measures (e.g. ASLR and NX) are useless as anything more than marketing fluff because they're not implemented consistently.
Seriously, I've been in the security field for almost 15 years and dealt with reporting vulnerabilities to dozens of companies. Microsoft is a pain to deal with because of their compatibility matrices and long release cycles, but they're generally competent. Whereas Apple is just an absolute train-wreck. The only reason every Mac isn't infested with malware is that they're not a big enough chunk of the market for it to be worth the effort. If they ever cross the magic 15% threshold they're in for a very rude awakening.
Your guess is correct; for rarely followed code paths it does take significantly longer to (aggressively) optimize the code than it does to run it. Also, premature optimization can generate pathologically suboptimal code, meaning the performance can be much worse than the unoptimized case.
My understanding of how Crankshaft works is that the emitted code keeps some basic information about the data and frequency for any given code path (it's probably function level, but I don't know the code so I can't say for sure). Once the data and frequency of travel crosses a threshold the code path gets flagged for aggressive optimization. This kind of housekeeping adds very little overhead, so the decision cost overall should be very low. And the useful thing about spot optimizations like this is that their relative infrequency means that you can afford to do really aggressive optimizations that would be far too expensive to run over all of the code at load time.
The funny thing is that none of this is new. It's all decades-old compiler research stuff that mostly evolved out of the Self language. And Mozilla's tracing engine attempts similar optimizations, although it uses a different technology with different strengths and weaknesses.
If you're using SunSpider as your sole benchmark then you're already behind. SunSpider has outlived its usefulness (which the article touches on). In order to get a win of a few hundredths of a percent on SunSpider you have to add in premature optimizations that hurt page-load times and the performance of long running JavaScript applications. (Or you could add some dubious optimizations that are targeted specifically to the test, but that sounds a bit like cheating on a benchmark to me.)
SunSpider was good for it's time because it set a minimum bar for all browsers. However, the beta versions of all the new browsers are now within a hair's width of each other's performance on SunSpider. Rather than split those hairs, we need a new generation of tests that more accurately models real-world usage and JavaScript in the large. Mozilla and Google are both moving in that direction with Kraken and the V8 benchmark suites (respectively), but it's just a start. I'd like to see comparable benchmarks from every JS engine maker, or maybe a broadly-scoped, independent benchmark.
This is pure marketing. If they want to prove to me it's secure, ask for a public code review and reward those who find clear problems, and compile from that reworked code.
The codebase (minus PDF, Flash, and branding) is open source. Google pays out anywhere from $500 to $3113.70 to anyone who reports Chrome/Chromium security vulnerabilities to them. And if you look at the release notes on Chrome and Safari it's obvious that Google has a full-time team searching for and fixing security issues in both Chrome and WebKit. I'm not sure what else you want them to do, because they're already going well beyond anything you suggested.
You "do a lot of internet marketing" and you don't understand the difference between returning a competitor's site as a search result (what you identified) and stealing a competitor's search results then presenting them as your own (what is being accused)? Might I suggest that you consider a different profession in which you might be more qualified?
If you don't like the single user version then install the system-wide version from the google pack. And it doesn't leave past versions around; it leaves exactly one previous version when it's updating because it uses differential compression against the old version and falls back to the previous version if the update failed.
He who lives without folly is less wise than he believes.