>> MIKE: So, my name is Mike and I've been working on Chrome for about three years now
and I work on all parts of the internal. So, I'm mostly on the backend, touch plug-ins
a little bit early on, and work on some networking related things, a little bit of JavaScript
integrations. So ultimately what a Web browser does is it takes some set of content and then
it's going to render it on the screen, most commonly that's HTML. So, there's nothing
particularly tricky about that, it's been done for many years. But when we invented
JavaScript, the whole point of JavaScript was so that people could dynamically change
what that page looks like without having to change statically though the contents. So,
in order to do that, you have to come up with a set of APIs and those APIs are what we call
the DOM, the Document Object Model. And it's the--it's the API that's available to JavaScript
for changing the content that's being rendered. Most Web pages today use a fair amount of
DOM bindings, especially the kind of Web 2.0; and Gmails certainly use a lot of documents,
spreadsheets, and things like that. But pretty much, you know, all the major Web pages use
it in some form, whether it's being, you know, it's doing a little stack ticker or displaying
advertisements or what have you. Everybody's got some of that JavaScript. So, a lot of
times we talk about how JavaScript is fast and, you know, Apple's got some great benchmarks,
we've got some benchmarks for measuring JavaScript speed. But generally what they're measuring
is just how fast the JavaScript into this. So, the second part of JavaScript is actually
modifying the UI and that's where the DOM comes in. So, you use JavaScript to modify
UI. And then there are two halves that become important: A. How quickly can you run your
JavaScript, that's critical; and then B. How fast can you make those API transitions to
and from out of JavaScript and into the browser? The browser is usually written in C++, all
the major browsers are, and of course, your JavaScript is in JavaScript. So, you've got
two very different programming languages and you're transitioning back and forth between
them and that's what’s improving DOM parts is about. Well, ultimately we're just trying
to make Web pages run really fast. When Web pages were static, that didn't involve JavaScript,
it didn't involve bindings. But, of course, for the long past, having static Web pages.
So application programmers today, they're building very sophisticated things inside
a JavaScript and HTML, and they need that to run just as fast in the Web as it would
run on the desktop application. So a lot of times you're constructing a user interface
based on dynamic data that's changing, based on user inputs, based on stuff you're downloading
incrementally off the Web. And so, though you use JavaScript it's the glue that injects
it into the User Interface. So, the performance goal for us is to just make sure that Web
pages run really fast, and the user has a really good experience. If it takes a long
time to add 10,000 rows to a table, well, then the user is going to be sitting there
waiting and the users don't like to do that. So we just want to make these applications
run really well. All right. So we started out with WebKit, which is a pretty nice rendering
engine for Web content; that comes from Apple. They did a fantastic job of optimizing a lot
of the CSS patterns and things that people are doing. One of the things that we change,
all though, they had a good job with script engine, we did a--we thought we could do a
little bit better with V8, so we came out with V8 instead. But when you change the JavaScript
engine, the interface between the JavaScript and the C++ side all changes. So there are
some elements that are common, the DOM API itself is exactly the same, whether you're
using either browser, at least that’s our intention. But we need to re-optimize all
those code paths. And because we do things differently in V8 to make it go fast as a
JavaScript engine that does have effect on how we--how we talk to the browser. So some
of the things that we ran into are simple things like just converting strings way too
often, you start out with a string in JavaScript and you've got to use that string in the C++
side. It sounds so simple and yet so many projects run into trouble with just string
conversions and it really does add up. Other things, when you're dynamically creating lots
of notes, you'd need to be able to create them really fast, and so, we found ways that
we can cache the templates of what a node should look like. So the first time it's created,
it's a tiny bit slower, and we're talking about some millisecond here, right. But when
you add them up, in terms of the way people are doing it, you know, thousand and thousands
of times in the Web page, it matters. Also looking at the way events fire, so a lot of
times people have a large complicated Web page and they have a lot of different things
that can change, so they're monitoring for events all around that page. And we have to
make sure that that browsers doesn't get slow when there are too many event handlers being
registered and so forth. We put in this new spiffy JavaScript engine, and in order to
do that we have to completely rewrite the mechanism where--for how you communicate between
JavaScript over a slow Web browser. Probably, the biggest difference between V8 and other
JavaScript engines is that V8--the garbage collector, we use handles to reference everything
rather than reference counting, and that's a very big shift. So, suddenly passing strings
between the two environments becomes really difficult. And I say strings but it's actually
any piece of data that you want to pass between the two. In the kind of the old model, you
could reference count. I mean, you could pass those straight across and you can build a
couple of very simple mechanisms where data just passes very cleanly. And that's the advantage
of the old model. But that old model didn't have nearly as powerful of a garbage collector.
The Garbage Collector in V8 is extremely important because if you're going to run complicated
JavaScript Applications, you need SPL to just run in the background, you don't even notice.
And so, you'll hear the V8 team talk about DC process, and they want to be able to animate
these complicated things, and literally, you'd never see it stop. Whereas in a browser that's
got a heavy Garbage Collector, you'll see a kind of--and then go and then go. So because
we made this shift from a completely referenced kind of model over to this new model which
is, you know, it's handle-based and has its own collection of memory-base separate from
the browser. We lose some of the ability to just share these things back and forth fairly
seamlessly. So we have to optimize--optimize it a lot. So you could actually call it just
a log in Chrome 1.0, I suppose. It's a place where we want it and it’s fast. And a lot
of this product was about bringing back-ups. So I think we did that. We have a lot of problems
with just--we were--the way we allocate it, it wasn’t as fast as it could be. There
are places where when we were doing our look-up teams, the dynamic properties, they want it
as fast as they should be for the DOM bindings, the bindings. The bindings are kind of--it's
a well-known API, so you can change the way you do look-ups a little bit to improve speed
there. We've also looked at taking pieces of the C++ DOM and actually moving it into
JavaScript. So where's--previously, you would have to always be going back and forth from
one language to the other. Now, by just moving all over in JavaScript you can just stay over
here with a much, much fewer transitions back to the C++ site. Well--so one of the biggest
things we had to do just when we started thinking about the project was find a good way to measure
it. You can't fix what you can't measure fundamentally. And the benchmarks that are out there for
JavaScript, yeah, they're pretty good. They measure the JavaScript, but they measure without
changing the user interface. There is a good one from Mozilla, it's just been created in
the past year, I think, after we shift Chrome, it's when it first shift, but--and it's called
yMail (ph), and they do a nice job. We also wrote a number of internal benchmarks that
we used where we gone around with JavaScript developers in house, and we said, "Hey, you
know, what's causing your slowness? What did you have to work around in JavaScript?" And
then we take a look at why the browser is slow. And we put this into the benchmark.
And once it’s in the benchmark, then we can finally, you know, just continue to optimize
it, and things become a lot easier at that point. Hopefully, you get the most important
elements, the things that are most critical to go fast as part of your benchmark so that
you're optimizing the rights things. No one ever knows for sure, that's kind of the trouble
of benchmarking, but we try to mitigate that by just taking lots of different things and
measuring them all. And we want to go the fastest in all of them. Web pages are pretty
complicated. You have a lot of different things. There are a million different things that
happen in the browser depending on which Webpage you're looking at. You're going to see different
potential problems, but they do all start with some common elements. You know, everybody
is downloading [INDISTINCT] off the network. And the average size of a Webpage is increased
by a factor of 10 over the last 10 years, right? It wasn’t that long ago where people
said, "Oh, your Web pages won't be much larger than 35 kilobytes." But now, you can go to
CNN, you can look at almost a megabyte. The average size is well over 300 kilobytes. So
how fast you can download that content is critical. Once you've downloaded it, you know,
a lot of it has JavaScript. This is why JavaScript has been such a heavy emphasis of Chrome.
And of course, just your broad rendering engine just how fast it is, that's why we pick WebKit
to begin with and it's because it did come a little bit later after some of the newer
technologies have been a little bit more established, things like style, sheets and such. And it's
faster doing them. So, anyway, the networking is one area which is probably the biggest,
it hits everybody. It varies though because you could be on a fast network, maybe you're
on a local LAN, you got 10 megabits straight to your computer, or you can be on a mobile
network where you've got less than 250 kilobits, and it's really kind of like a network that
we did have 20 years ago. So try downloading 350 kilobytes data over that thing, and so,
it's going to take awhile. In the last couple of years, browsers have changed a lot specifically
while the HTTP specification allows two concurrent connections to a site up until about a year
and a half ago. That's was what OM browsers did. Microsoft was the first to change in
‘98; they went up to six and all the browsers have followed soon, that has dramatically
reduced [INDISTINCT] times. Another thing which has happened is the parallel downloading
of content in JavaScript. So Web pages are inherently fairly serialized. They can't do--they
kind of just have to go through one code path. And traditionally when the browser discovers
that it needs a style sheet or it needs a JavaScript in order to fully render the page,
it might walk and just stop rendering until that thing comes in and off the network. And
in fact they it has to do that but we're now a little bit smarter. So as soon as we see
something which previously would have blocked us, yes, we stop and we wait for that thing
to come. But while that's downloading, we continue to scan through the page looking
ahead for other things that we're going to need and we get those to start in right away,
while we're waiting for the download. So, Web pages load a lot faster with that feature.
And other browsers are doing that as well. For the future, we're looking at changing
anything that we can, in order to bring the latency down. Now, with protocols and networking,
they're a lot more limited, so, you know, Google got a start by building fast and scalable
Web servers, right? And we were doing that specifically so that we could build a fast
and scalable search engine. And then, a couple of years ago, we started on the browser, now
I got the networking piece in the middle. And that, the reason the networking piece
is the last, to kind of get changed, is because so much depends on it. You've got all the
browsers already deployed, and you got all the servers already deployed. So, we are looking
at ways that we can change into by augments in the protocol, but we're going to do that
on an open sourced way and good standards bodies and such. Anything that we can do to
make web pages load faster, we think is good for everyone. We've got a couple of things
that we're looking at, so if you, if you break down what a Web page looks like today, it's
a lot different than it was 10 years ago. So when the Web started out; you had your
basic HTML page, you might have a couple of images and that was it. Today, in addition
to the basic Web page, you've got far more images, you've got Java script, you've got
advertisements, you've got movies, you've got style sheets, so you might have, literally
on the CNN page, you might have 150 different things to download in order to get--and because
the way the Web works, you know, we've been fairly limited in how fast we can download
a 150 different things. People that write their contents, split it across multiple domain,
so that browsers can make six connections to that domain, in parallel of six connections
to this domain, in parallel of six connections to this domain. Some Web pages will actually
have, you know, 30 or 40 connections open, concurrently and that's just to work around
kind of a serialized nature of the Web. So, can we tell the browser more quickly that
it has more resources to get than what it currently does and can we help the browser
get them concurrently rather than serially? We think we can, but, you know, it’s a work
to be done in the future. So, when we first built Chrome as a multi-process browser, we
were primarily thinking of the security and robustness properties and how could we make
the browser a really solid programming and application environment for the future. And
so, that's always been the first and foremost, but it turns out that there's actually some
performance benefits to it as well. For instance, I told you, like most--most Web pages are
pretty serial in nature. They only kind of do--they have to do step by step by step.
But by bringing it into multiple processes, we've actually got all of the Web work, that
is, you know, downloading a content, pulling things out of cache, that all happens in one
process and then the rendering work is happening in a different process. So, you might think
that, oh, well, if you're using multiple processes, you've suddenly introduced this overhead of
having to communicate with those two processes and that's true. And so, a lot of what we've
done is optimizing that path, so that the overhead of using multiple processes are very
small, but the benefit that comes out, is that we can now actually get work done in
parallel, whereas previously it had to be done in serial. Another performance advantage,
by isolating each tab of the browser into its own process, the work being done in one
tab doesn’t necessarily impact the work being done in another tab. So, probably we've
all had experiences where, maybe you've got one tab, which is doing something complicated,
maybe it's, you know, Gmail and it's writing some really expensive JavaScript or whatever
and you switch over to another tab, and that's the one you're trying to use now, but that
other tab in the background is still getting in your way, and if you're--if you're just
one process, there's nothing you can do about this. But Chrome has a couple of things that
you can do about it. First, you know that tab is in the background, we can run it a
lower priority, operating systems that had lower priority processes forever. And so,
by just having partitions, we can now take advantage of this operating system features,
which otherwise, wouldn’t be available to us. Another advantage, you know, if you run
a browser over time, you know, it's very difficult to not have it, kind of get bigger and bigger,
and of course, we work on that, the memory leaks are awful. We want to keep all that
to a minimum. But having a platform for robustness to avoid it is also really beneficial. So
when you load a Web page in one process, we have a very natural pruning point, which is
when you close that tab, we get rid of the whole process, everything, lock, stock and
barrel, it’s gone. So, that's where our multi-process architecture allows us to just
cleave off the big chunk of work. So, if you ever do have a runaway tab, if you ever do
have, you know, it's just getting too big; close down those tabs and it will restore
back to normal without having to affect, you know, the other tabs that are running okay.