David Mandelin\’s blog

I’ve been trying out Chrome on my Vista machine at home, and I read a few hundred comments on Chrome last night on Digg. Here are my first thoughts, just as a browser user and an engineer.

Responsiveness. The most noticable things right away are that the UI is minimalistic and very responsive. The screen responds promptly to clicks, and UI elements appear, disappear, and move around very quickly. Responsiveness makes any tool (or toy) more enjoyable to use. So I like that a lot.

AFAIK, Chrome’s UI is straight C++, so that plus the minimalism should make it very fast. Firefox, of course, has a bigger UI coded in XUL/JS, which gives FF more features and excellent extensibility. I would never want to see FF give up extensibility, but I would sure like a snappier FF. I have no idea what that would take; speeding up JS should help, perhaps some sort of XUL tuning or overhaul is needed as well.

Process Isolation for Tabs. Less technically known as process-per-tab. This looks great. Diggers love the idea as well. Personally, I want it so that one bad web page or Flash app doesn’t hang my whole browser. That seems to be what the Digg users like best about Chrome too. There’s also reliability-one really bad page won’t crash the whole browser, although FF crashes are rare for me anyway and the state restore option makes crashing not too painful. And security, so that a maliciously bad page can’t overwrite memory on anything else. I haven’t used Chrome enough yet to see these situations come into play, so I don’t know it will work in practice, but for now I’ll assume they got it right. There’s still the question of whether the Windows schedulers give enough isolation to maintain performance, too.

Anyway, I want it.

There is a tradeoff: Chome seems to use more memory, at least with several pages open. (I tend to run with 20-80 pages open at a time.) Chrome actually tracks the memory nicely. Type about:memory into the location bar, and you get a summary of memory for all your open browsers, including FF if it’s running. Very cool.

<technical-gobbledygook>Memory consumption on modern OSs is complex enough so that it’s difficult even to define clearly. Chrome’s “task manager” (press Shift+Esc) is reporting the private working set size. This is the same number Vista Task Manager displays by default. The private working set size is the amount of physical RAM allocated for the exclusive use of a process. (The full working set includes physical RAM accessible to to the process but shared with others. The term “working set” comes from the OS’s allocation strategy, which tries to allocate just enough physical RAM to cover the virtual memory the process touches frequently, which is called the “working set”.) about:memory also shows the virtual memory allocation (I think Windows calls it the “commit size”), which is the “true” (ignoring a few complexities, I’m sure) amount of memory used by the process. I think that for an active app, the total allocation is more relevant, because either it will be in memory, or frequently paged in and out, bogging everything down. For paused background stuff, the working set can be more important, but if it’s paged out, the total size will determine how long it takes to come back up when you ask for it. On my system, Chrome was using more memory by both metrics, but I didn’t use Chrome heavily enough to see any serious paging or thrashing, so I don’t know how it plays out in practice yet.</technical-gobbledygook>

The extra memory consumption might make Chrome less suitable for mobile devices. So process per tab should be an option for FF, but not required. Also because not everyone will want it on their non-mobile devices.

Ideally, I think process, thread, and DOM tree (i.e., tab) should be orthogonal concepts in the browser platform. The DOM tree is a unit of visual display and window control. The process is a memory protection domain. The thread is a unit of sequential execution. The user and the browser would control the policy of how many processes and threads are created and how they are assigned to tabs.

As an example of what you could do with this, you might have a default policy where each tab is a process, with each separate script or plugin being a separate thread inside that process. Thus, the tab is protected from other tabs, and its dynamic elements can run concurrently. But now say that one of those scripts loops. The other scripts might still be running OK, but with less CPU because of the looping script. If you want, you could shut down just this tab, and leave the other tabs unchanged. It’s dangerous to kill just one thread, because it can leave the memory inside the process inconsistent. But at worst, only this tab would crash. If it did, you could reload the page with a policy giving each dynamic element its own process. At this point, you could kill just one element on the page while leaving the rest running.

A more exotic example would be to assign two processes to one tab. This seems weird, but it would be possible if the 3 concepts were orthogonal. One use would be to allow two other elements (tabs or scripts) to interact closely with a element. Interprocess communication is expensive, but as long as the other two elements use the shared element one at time, we can just map the shared item into both processes, so they can access it relatively quickly.

Of course, that’s a lot of work. I hear there’s also some problem where the MacOS Core Graphics APIs make it harder to implement multiple processes for one browser window than it is on Windows.

Awesome Bar and Places. Chrome has some version of FF’s Awesome Bar and Places. Which is a good thing-at this point I would find it painful to use a browser that didn’t. I think the location bar has some Googlyness in it too, like Google Suggest or something. I started typing the names of some of my favorite blogs, and it got the popular ones after a few letters even though I’d never visited them before in Chome. That was pretty nice, but I imagine after you’ve used the browser for a while, you have visited your favorites anyway, so it won’t matter too much. But I use and love FF’s Awesome Bar so much, I think I would like having search/suggest even more integrated with it. It’s a small thing, but it could make the browser just that little bit more responsive and direct.

So far I’ve found the bookmarks interface kind of weird. It bothers me that I either have no bookmarks menu at all, or else an ugly toolbar strip across the top of the browser. But I think it’s good they’re trying something new-I think Places is great but will continue to improve. Personally, I use the Awesome Bar for all navigation to a single site. I only use the bookmarks menu to open a group in tabs (e.g., morning blog reading), or to bring up a group in the Ctrl+B view and click on various items in turn (e.g., Youtube playlist). So there’s probably some mystical third design (not to mention 17 existing FF extensions) that would be better for me.

I’m really not excited by tabs on top of the window, or the thumbnail view of open pages. That stuff doesn’t work when you have 26 tabs open.

V8, blah blah blah. V8 is the other hot topic on Digg. I’ve heard Zimbra runs really well on Chrome, but I personally haven’t done anything with it as a user where I really noticed a difference. TraceMonkey vs. V8 has been covered elsewhere, so I’m not going to bother with that. Plus all these VMs are pretty early, so I’m not terribly excited about day-by-day benchmarks.

What I am immediately interested in is what techniques the V8 team actually used, how it relates to my inline threading project, and what ideas I might be able to steal from it. But I’ll have to read the code and report on that another day.