Google Chrome Keeps Pace with Web App Advances

In the pages that follow, I give a rundown of the new Chrome browser from Google from a technical perspective. I’m not giving every detail of the nuts and bolts of Chrome, nor am I giving an overview of the cool new features. Rather, this is an overview of some of the interesting technical aspects that I discovered while reading the docs on Chrome and looking at some of the open-source code.

If you’re a manager who wants a technical overview, read on. If you’re a developer, you’ll want to read this before reading my future articles about development for Chrome.

Multiprocessing: Finally!

For those of us who spend 12 hours or more a day at our computer (that would be me), we often start our browser at the beginning of the day and keep opening up new tabs and new tabs as the day progresses. I’m not kidding: There are times I’ll have 50 tabs open in Firefox. (Okay, maybe that’s indicative of other problems and I shouldn’t admit that. Ahem, anyway…) And as we open more and more tabs, while closing a few here and there, the memory consumed by the browser just keeps growing and growing. I’ve seen the browser easily take up over 300,000K; there have been a few occasions where it even topped out at a gig. (Again, maybe I shouldn’t admit that!)

Now while Chrome doesn’t totally fix the memory size problem, it does help manage the issue by reducing fragmentation problems. In one of the traditional browsers, the browser gets one set of virtual memory allocated for the single process. Each tab, of course, takes up a block of memory within this total set. And as you open tabs, more memory is allocated. But as you close tabs, the memory left behind isn’t always big enough for future tabs, and you end up with the standard fragmented memory problem. (Now I should probably clarify that this is the claim that Google makes; I haven’t looked at the Firefox source code to find out for sure how it handles fragmented memory.)

But with Chrome, each tab gets its own process. You heard that right: Not just each Chrome window, but each tab. I’ve been doing development for some 20 years now, and I have to be honest: It has never once occurred to me to have a single window hosting mulitple processes. But that’s exactly what Chrome does.

Now being a skeptic at heart, I wasn’t sure I believed this without testing it myself. I started up Process Explorer (from Microsoft’s SysInternals) along with Chrome. I then opened up new tabs and watched Process Explorer. Sure enough, there was a new process started as a new page loaded in each tab. When I would initially open a tab, Chrome wouldn’t allocate a new process yet. But when I typed an address into the tab and loaded an actual page into the tab, I saw a new instance of chrome.exe start up. With the help of Process Explorer, I could look at the command line Chrome used to launch the next instance of chrome.exe. The instance included various command-line parameters, including --type=renderer which apparently tells the instance it’s a tab window, as well as one called --channel followed by a string of numbers, which is likely for locating and communicating with the parent process.

This happened each time I loaded a page in a new tab; I had multiple instances of chrome.exe running. But further, if I had an existing tab with a page in it, and I went to the address bar and typed in a new URL, that page’s associated chrome.exe instance closed and a new instance of chrome.exe started. That’s perfect: Instead of trying to clean out the memory associated with the existing page that’s closing, chrome just wipes out the whole process and starts fresh. And that’s one more way Chrome stops memory fragmentation, as well as protection and isolation between pages.

But what’s even more interesting is I saw an oddity when I loaded www.yahoo.com. I saw two processes starting up. But for other smaller pages like www.google.com, I only saw one process. I had a pretty good idea what that second process was, and when I looked at the command line parameters, my suspicion was correct: The --type command-line parameter is now set to plugin, and there’s an additional parameter called --plugin-path that is set to:

c:\windows\system32\macromed\flash\npswf32.dll

That’s the Flash player; Chrome starts even another process for the Flash player embedded inside the page!

Being a good engineer who likes to blow things up (virtually speaking that is), I did the easiest test I could think of. I killed that process only while keeping the Yahoo page open in Chrome.

Bingo! As soon as I did, the Chrome tab displaying the Yahoo page showed a message at the top of the page, and replaced the Flash windows (wait, plural? Apparently the single process controlled all the Flash plugins for the page) with the Flash logo and a sad face on top of it, as in the following figure.

Figure 1. Flash crashing in Chrome.

And sure enough, the Yahoo page was still usable. In other words, a plugin crashed without crashing the browser. And for a guy who likes to have a few tabs open at once, that’s a godsend.

Just to make sure I tested everything completely (this was strictly for scientific purposes, of course), I killed the process for the Yahoo page as well. (I suppose Google will be glad I didn’t kill their page instead.) This time, the whole page turned black with a sad face and a message, as shown here:

Figure 2. Yahoo page crashing.

Meanwhile, the other pages remained running, as I hoped. Again, that’s a godsend. No more having the browser crash in my MySpace tab thanks to a bad YouTube video that was the real source of the crash while I’m right in the middle of an online banking session in another tab where I was making a transfer to hopefully prevent a payment for an amazon.com charge from overdrafting my account, a payment that was in progress in yet another tab showing the amazon.com page for a book I was buying to hopefully provide details to help me answer a question that I was answering from a reader of my blog in yet another tab, a question that at first I wasn't sure the answer to and as a diversion I started watching a YouTube video somebody sent me on MySpace before I realized there might be a book available that would help me out. (See how I operate sometimes? Now there’s a browser that supports my neurotic ways.)

Incidentally, Chrome actually has its own task manager you can try out. While inside Chrome, press Shift+Esc to open it up. It even lets you kill processes within Chrome, having the same effect as when I killed them from Process Explorer. And if you really want a lot of info about the tasks, the Chrome’s Task Manager has a “Stats for nerds” link on it, which opens up a new page in Chrome showing all sorts of great techie information on the processes. Oh yeah, and at the top of the page it has the other browsers that are running (such as Firefox) and shows their memory consumption for comparison (or competition, as Google probably sees it).

And incidentally to this incidental, the “Stats for nerds” page is accessible directly by just typing in the address about:memory (which is in the same style as the about name in the other browsers). Try these about pages as well if you’re using Chrome: about:cache, about:dns, about:histrograms, about:internets, about:network, about:plugins, about:stats, about:version.

Rendering Engine

If somebody were to start out fresh writing a brand new browser, one particularly difficult part is the rendering engine. (I know—I developed an early rendering engine some 10 years ago in Delphi. The engine is long gone these days, and even if anyone found it, it wouldn’t be very useful as it’s totally outdated.) Google made the right choice on this one: Instead of starting from scratch, they picked an existing open-source rendering engine that’s mature and packed with several great features such as speed. The one they chose is WebKit, which, interestingly enough, was developed by Apple (which in turn based its work on an early code base called KDE HTML Layout Engine). Apple’s own development led to the engine that is the basis of their Safari Web browser; they then made the engine open source (WebKit), and now Google is basing its engine off that.

This means the rendering in Chrome isn’t buggy and slow. It’s fast, and it works. But I found something that was intriguing: While researching this article, I read that the early versions of WebKit has SVG built in. So I tried something on a whim: I opened a .svg file in chrome—not an HTML file that displays SVG, but an .svg file directly. And guess what! It rendered it just fine. For me, this is particularly intriguing, because various forces in the industry (such as Microsoft themselves, as well as Adobe) have kind of pushed SVG aside, forcing many people to drop development on it. It’s hard to say how this will impact the world of SVG, but it’s definitely interesting. (However, I should add a caveat: After writing this, I did some searching and found a discussion where somebody pointed out that Chrome’s SVG implementation doesn’t handle animation. That’s a major drawback, so we’ll have to wait and see if Google beefs up the support, or if this minimal SVG support is just an artifact within WebKit. Personally, I’d like to see them add to the support, because I feel SVG is still an excellent tool for interactive vector graphics that has gotten a raw deal in the past year or so.)