V8 is ACTUALLY fast and has been for years. I don't know how that could even be contested. Mozilla internally knows that v8 was/is fast and has been trying to beat them.
Chrome does use more memory if you have a ton of tabs open, but it also is still fast. I haven't noticed a substantial amount of memory leakage, but I guess that depends. Regardless, the memory leakage can be subdued by reopening a tab rather than reopening the app.
The marketing that Mozilla puts out is the problem, not Google's marketing.
I've noticed substantial improvement using Chrome in real-world use cases. The optimizations I've experienced happen in larger apps that hold much more in memory (I don't consider Facebook/Gmail/Wordpress especially object intensive or CPU intensive, do you?).
Speaking historically, you would say that Firefox 3.5 was as fast as Chrome 3 in real-world use cases? Or that Firefox 4 paralleled Chrome 10? Mozilla has been pushing that they're faster, better, ahead-of-the-curve for years and many people have switched because they haven't delivered until very recently.
Maybe only 10% of that is due to the JIT compiler but you can't easily say Chrome hasn't been faster for an extended period of time since it was released. I'm unsure of whether the remaining 90% is due to DOM interaction, rendering, or just perceived crappiness but it exists nonetheless.
"I'm unsure of whether the remaining 90% is due to DOM interaction, rendering, or just perceived crappiness but it exists nonetheless."
A mix of all of that. For the DOM part Mozilla is developing new bindings (called Paris bindings) to close the performance gap compared to the competition [1]. Johnny Stenbeck has written two articles which give an interesting insight into past, present and future DOM bindings in Gecko [2][3]. Azure is Mozilla's new rendering API which even in its infancy showed some promising performance improvements [4][5]. Unfortunately work on Azure hasn't been progressing as fast as I had hoped. AFAIK only the canvas element is currently using Azure for rendering, the rest (ui + content) is still based on legacy APIs. On the JavaScript front there's IonMonkey, a brand new JIT compiler developed from scratch [6]. It's still in ongoing development and lacks many optimizations so right now it's slower than Mozilla's current JIT compilers in many tests [7].
Notable cases of excessive reflows:
Hovering over the sidebar links in gmail (updates almost the entire page on each hover)
Hovering over "related videos" links on youtube (updates all of the related videos area, area around the video, video description, and comment area)
A lot of the javascript powered animations/slideshows you see on web pages. (Again, its not uncommon to see almost the entire page being updated here)
A few IE test drive tests like BetaFishIE, Santa's workshop, and the CSS maze solver.
When the above bug is fixed, Gecko should be much better in all of these cases.
Chrome does use more memory if you have a ton of tabs open, but it also is still fast. I haven't noticed a substantial amount of memory leakage, but I guess that depends. Regardless, the memory leakage can be subdued by reopening a tab rather than reopening the app.
The marketing that Mozilla puts out is the problem, not Google's marketing.
http://arewefastyet.com/old-awfy.php
http://arewefastyet.com/