Dr. Scheinker's insight on simple repetitive tasks vs. complex infrequent tasks is spot on. Fortunate to get a chance to work with him at Stanford. Hope more realize the role of A.I. as not necessarily one that replaces humans rather one that augments them.

I used to hold this opinion (benchmarks != real world speed) until recently. But I have found that the test results compare favourably to real world usage. For example Google wave is sluggish on firefox while chrome has no problems with it.

My javascript performance comparison between Firefox 3.6 and Chrome and Safari http://www.manu-j.com/blog/firefox-3-6-vs-chrome-vs-safari-javascript-performance/432/

As usual, Firefox performance on the v8 benchmark is pathetic where Chrome is more than 10 times faster.It is 24% faster than version 3.5.4 in V8 but it is clearly not enough. In the sunspider test, chrome is 2 times as fast as firefox. In this test, 3.6 is 17% faster than 3.5.4. Safari too comfortably beats Firefox in both these benchmarks

My javascript performance comparison between Firefox 3.6 and Chrome and Safari http://www.manu-j.com/blog/firefox-3-6-vs-chrome-vs-safari-javascript-performance/432/

No, I (or rather chrome devs) meant Cocoa. Take a look the relevant bug discussion

You can use chromium if you don't want to use the google branded Chrome. Chromium will not send any data to anyone.

I'm not a mac dev and what i'm posting here is gleaned from several svn log entries. So it might be wrong and inaccurate :). The chrome architecture is that there is a main process which handles the UI and there is one process per site which is launched but do not handle the UI. In Mac, the one process per site works but if you open up Activity Monitor you will see that the additional processes are shown as "Not responding" though in reality they are.

What is happening here is that OS-X expects the additional processes to respond to UI events and since they don't mark them as "Not Responding". Two solutions have been proposed

1. have dummy code which responds to UI events to keep OS-X happy
2. Rip out the Cocoa code from the additional processes which will make OS-X not expect the process to respond to UI events.

I have been following chrome for mac development closely on my blog with weekly updates. Here is a list of the functionality as of Build 17426
What Works

* Almost All Websites
* Bookmark pages
* Most visited sites
* Open link in new tab
* Open new tabs
* Omnibox
* Back, Forward, Reload
* Open link in new window
* Drag a tab to make a window
* Launch new tab
* Cut, Copy, Paste
* Keyboard shortcuts
* about:version, about:dns, about:crash, about:histograms
* Find in page
* History with search
* Form Fill
* Delete Thumbnail in New Tab Page
* Window Positions Remembered
* View Source with synatx highlighting and clickable links

What Doesn't Work

* Plugins (No flash -> No youtube)
* Bookmarks Bar
* Print
* about:network, about:memory
* Web Inspector
* Input methods such as Kotoeri (Japanese)
* Preferences (Partial implementation)
* Full Screen Browsing
* Favicon (thanks brin)

Anyway, chrome beta is coming on nicely and hopefully I will be able to ditch safari for good. [Firefox is my main browser but I do need a second browser].
I have been keeping track of mac chrome and in the last two months it has become quite stable and only thing missing is flash. Some here would even consider that a feature.

At least it is in one place. Here it seems files are scattered all over the place and in non obvious locations.

"Empty cache", doesn't delete everything.
before: 737M -Caches-
after: 571M -Caches-
This is seriously fucked up.

There dare daily builds available for all platforms here http://build.chromium.org/buildbot/snapshots/ For the mac build, to get an idea about what status it is in and what works and what doesn't you can see my post on it http://www.manu-j.com/blog/download-updated-native-google-chrome-for-mac-os-x/230/

It has given me a new appreciation for slashdot moderation!