Google I/O 2012 - Chrome Developer Tools Evolution

>>Sam Dutton: Hi, everyone. I think we're ready to begin if you would like to take a
seat. Glad to see everyone here. Yeah, we're here
to talk about the Chrome Development Tools today. If you are here for something else,
I think you should stay because it will be a really good session.
My name is Sam Dutton, I'm a developer advocate for Google Chrome. I'm based in London.
>>Pavel Feldman: And I'm Pavel Feldman, software engineer working at Google Chrome.
>>Sam Dutton: And yeah, we're going to show you some great new features in Tools and hopefully
some stuff that can make your life easier as a developer.
You know, 2012 has just been an incredible year on the Web. I was looking back at the
session that Pavel did with -- Paul Irish is in the house somewhere -- last year, and
it amazes me how much the Chrome Tools have evolved in that time, how much the Web has
changed in that time. It just seems like the normal thing now for
you guys to be building these apps that are incredibly complex and really pushing the
limits of development on the clients' side. And I think that one thing I've found is that
in a context, you know, a really great text editor just isn't always enough. And with
that in mind I think that's where the Chrome Dev Tools come in. So what are we going to
talk about today? Well, we're going to run through some tools that we hope will boost
your productivity. And we'll also be looking in some detail at using the tools to do mobile
Web developments. We'll also be looking at this idea of responsiveness. You know, what
is it? How do we measure it and how do we deal with it in a scientific way rather than
with guesswork? And you know, in a balance to that, also looking
at memory and making sure that we stay on top of that.
And all through this we'll be looking at a whole bunch of new features in the Tools.
But first, we just wanted to say, you know, I really big tip of the hat to all the people
who have contributed to the Tools in the last year with bug reports, feature requests and,
you know, by committing code. We've got a list here of some stuff, just
touching the surface of stuff that's been put into the Tools in the last year just from
user requests and user codes, you know, fantastic contributions, really good stuff.
Just to pick on one of these things, this business of caching. Caching is a good thing,
but it can be a real pain for developers. Particularly when you're dealing with situations
where assets are being loaded dynamically after the onload event and in those situations
a hard reload or whatever just isn't enough. So we have two new features in the tools.
From the network panel you can right-click and clear the browser cache or you can even
just turn off caching from the settings page. So yeah, great stuff from our users, and we're
really grateful for that. So with that in mind, we've got this roomful
of great developers, we thought we would take this opportunity to try and get from you guys
some ideas about what you would like right here, right now, to see next in the Tools.
You know, what challenges are you facing now? What would you like to see?
Pavel? >>Pavel Feldman: Right, guys, that's your
only opportunity, unique opportunity, to request something, and even without filing a bug I
will be implementing it for you. So please shout out what you want from the devtools
and we'll type it in and we'll make sure it's not lost.
>>Sam Dutton: Right here, right now, shout it out.
>>> [Inaudible - No Mic]. >>Sam Dutton: Okay, next, please.
>>> [Inaudible - No Mic]. >>> [Inaudible - No Mic].
>>Sam Dutton: Thanks very much. One here.
>>> [Inaudible - No Mic] >>Sam Dutton: And while on this side?
>>> [Inaudible - No Mic]. >>Sam Dutton: That we already have.
>>Pavel Feldman: Let me put it in. I will be happy to file the bug and close it.
>>Sam Dutton: Okay. Down the front. >>> Storing edited CSS.
>>> [Inaudible - No Mic]. >>Sam Dutton: Okay. And who else down in the
front? >>> [Inaudible - No Mic].
>>Sam Dutton: Here. >>> [Inaudible - No Mic].
>>Sam Dutton: Yes? >>> [Inaudible - No Mic].
>>Sam Dutton: Maybe two more. >>> [Inaudible - No Mic].
>>Sam Dutton: Like by the system in other words, like for San Serif or whatever. Behind
you there. >>> Bigger text in the developer tools.
>>Sam Dutton: Ah, we can help you with that. Bigger text.
>>Pavel Feldman: Bigger text. >>Sam Dutton: And right out the back.
>>> Support for CSS preprocessors. >>Sam Dutton: Yes. Good, good. That's fantastic.
>>Pavel Feldman: Okay. That's a good list. I'm happy to say that at least half of it
is already implemented. [ Laughter ]
>>Sam Dutton: That's great. We'll take that. >>Pavel Feldman: So I'm making sure it is
not lost. I'll be filing those by myself and probably will be implementing some of those
personally. >>Sam Dutton: And I'll be following him around
with a whip. [ Applause ]
>>Sam Dutton: So you know, like one of the things -- another thing we've noticed over
the last 12 months or so is that people are using the tools now more for actually writing
code, for building interfaces, not just for debugging.
And with that in mind, when the devtools team have built in some great features for working
in the tools in that way, and I was thinking about just how to demonstrate it, how it increases
productivity, and I was thinking about the devtools team themselves, like the devtools
team build the devtools to build the devtools. And good developers are really productive,
so who better to ask about productivity than Pavel Feldman. It would be a good opportunity
to give Pavel Feldman a chance to give us a master class, show us how he works.
>>Pavel Feldman: Now I feel flattered. Okay. Before we jump into the demos, let me
say a few words about the productivity. What do we expect from the Tools for productivity?
And for me it is getting into the source into where I need to fast. And being a part of
the screen or an action or a process, I like to jump instantly into the source code that
is responsible for this action. And vice versa, while looking at the source
I want to know what it is responsible for, how do I get the part of the screen that it
paints? While in the source code I am interested in
changing it and more importantly I'm interesting in seeing an immediate feedback.
And for those of you who have seen the Bret Victor's "Inventing on Principle" talk, if
you haven't, please make sure you check it out. That's an image from Bret's slides.
So the main principle Bret is talking about is the instant feedback. And as he goes through
his demos it is clear that the instant feedback not only increases your productivity, makes
you do things faster, but it also boosts your creativity, because when things are reflected
fast, when you have an instant feedback, you start experimenting. You go through the states
that you have otherwise not visit. Now that you have changed the source code
and you've seen the feedback, the essential part of the tool is to persist it.
So let me show you how these map into the devtools features.
I just started Chrome Canary, and it is a version of Chrome that is being updated on
your machine daily. It is built from the tip of the tree sources from WebKit and Chrome
and contains all the features that are implemented by this date, including the devtools ones.
So if you are a Web developer and you would like to make sure that everything works perfectly
on the next version of Chrome or if you'd like to use the tip of the tree devtools,
please use the Canary and please provide us with your feedback.
But more importantly, Canary can run side by side with your Chrome browser, so you no
longer need to choose whether you want to be on the Dev channel or Beta channel or Stable
to test for the changes, just have those two installed and that will be very convenient.
Oh, I have no connectivity. Sorry. It just plugged out.
So I'm navigating to the WebKit.org. And WebKit is the project where most of the Chrome devtools
source code belongs. We develop devtools fronted upstream.
Let me load it once again. Okay. Let's go to the backup plan. We have
a backup plan, don't we? Yeah, we do.
[ Laughter ] >>Pavel Feldman: So that's the WebKit. And
I'm going to do a lot of demos on the devtools, and we're going to hack devtools today, and
after this session you will be able to contribute your source code into the devtools yourself.
Now, I'm going to debug this page, but before I -- I'm not going to open the devtools using
the command option I, I'll do it different then.
I'm using remote debugging to start inspecting my page. And as you can see, remote debugging
works as a regular devtools. You can see the devtools is opened as a Web page. I can do
that because developer tools uses clients server architecture where browser acts as
a server and a front end acts as a client. So the devtools that you have in your browser
is in fact a Web app read in HTML, JavaScript, CSS, and it's talking to the backup using
Web Sockets. Did you know that? Okay, good.
Now, it's -- is it okay? Now it's time to debug. And as you can see, I open the devtools
doc to the right and let me [Indiscernible]. Here we go.
So what we are going to do here today is we are going to hack on the devtools itself because
I'm a devtools engineer. I want to show you what I'm doing everyday.
So that's regular old stuff. This is your Web page to the left. In my case it's devtools.
And that's your devtools to the right. [ Laughter ]
>>Sam Dutton: Pavel's life is so meta. >>Pavel Feldman: So we get a bit of inception
here, so don't get confused. Okay. Now, I've been working lately on the
timeline features. And as I was editing the timeline features, I noticed the timeline
does not really look like the rest of the Chrome.
We implemented it in WebKit, we were using these colorful gradients, 3D loops, we don't
really do that in Chrome, so I needed to fix it.
And when you were working in a UI like that, you need to go back and forth between the
page and your source code until what you see satisfies you.
Let's try to recreate this experience right now. I'm recording a couple of timelines in
here, and if you can see those gray zebra bars in the central part of the timeline,
let me make them a bit more conscious for you.
To do that I'm using the inspect element tool to locate the actual code responsible for
the zebra bar. And in here I can play around with its colors using the color meter. Let
me increase it or maybe play with the color. And I can do it dynamically in here. I have
a range of values I am choosing. And that's really a simplistic example of what Bret was
talking about, because as I go through these ranges I was just going to bump the conscious
a bit, but now I like the different color I can accept it.
Let's check if the sources were updated. And they were updated, so that's my new color.
Nice. But I think we have a bug because in the top part of this grid you can see the
overview. It also has the zebra bar, but it was not updated.
We are probably doing a bad job, we don't use constants here or the style we're using
is different. Let me do the same thing with the top area.
So I inspect it. Whoa. That's not CSS, so it's not going to work like that. We all love
CSS because it's declarative language. You change a value and you get an instant feedback,
everything updated live. Canvas is just JavaScript, imperative language.
Painting on a canvas, you can't go into the source code and change things dynamically,
or can you? For that let us try and find out what source
code is responsible for this painting. Remember we want to go from the screen into
the source code. For that I'm using command alt F, and I'm
just going to search for canvas. And it searches through all my source project, and through
the entire project. As you can see, we have a number of components that are using canvas,
but I think the timeline overview pane is the one that I need, so I'm jumping to it.
And while we are here let me say a few words about the new sources panel. So the sources
panel is the one where you are dealing with your source code. You are going to view it
there, you are going to modify it there, you are going to save it there, you're going to
jump on to the source code from your URL, so we need more real estate for that.
For that we now have collapsible debugger sidebars and expandable tree view with all
of your sources. And remember Web scales you need a lot of space for the list of your files.
But do you know what? You don't really need it at all times on your screen because you
can hit command O and jump to any file instantly. As I type, the list narrows down and I can
jump into a particular file or even a particular line number.
[ Applause ] >>Pavel Feldman: Now, remember what were we
doing? We were looking for canvas, right? So let us search for canvas.
There are a lot of occurrences. Does not work. Or let us go through -- oh, the methods. I'm
pressing command shift O and I get a list of all the functions in this file. And the
same very thing will work for your selectors in the style sheet. And as I type, the list
narrows down and I can jump to a particular function, but unfortunately there is no clue
on the canvas and the zebra stripes, so let's go on.
But I think I have an idea. I think this code uses the same color of the CSS. Do you remember
the color? What was the color there? >>> [Inaudible - No Mic].
>>Pavel Feldman: 50% gray? Any more options? So let's see if you're right.
I'm pressing control -- I'm using the context menu, control click in my case, and I'm looking
for local modifications, and I can see all the files that were edited within this editing
session. [ Applause ]
>>Pavel Feldman: And let me search for the old color definition. Here you go. Let me
grab the new one. Okay. >>> [Inaudible - No Mic].
>>Pavel Feldman: I am using context menu, local modifications. We'll go there in a bit.
Now, I'm replacing the code with a new value. And unlike in Bret's demos, unfortunately
the screen is not updated, but the reason is that we are not using requestAnimationFrame
to paint our canvas painting. We updated upon resize or any event that is being painted
in this overview. Let us try and keep those modifications while
resizing. Here you go.
So what happened under the hood is the V8 driven live edit, step in place, so when I
save the file the actual machine code generated for that source file, for that JavaScript,
was patched at runtime. And any subsequent execution of that code was using the new code.
Now, let's see if the local modifications, it's a context menu in here or in the scripts
navigator to the left, captured our changes. And of course, they are here.
Now, let's see if we actually like them. I'm going to go ahead and apply original content
for top and bottom areas. And, no, I like the new way more, okay. Applying
the revision content. I'm keeping the changes again. So as you can see, you can experiment
with the revisions of your edited source files, be it JavaScript or CSS. Now that we have
edited all, we need to save it. And for that we are going to use context menu and save
as. Here you can bind your source file to the file system location and all of the subsequent
saves are going to write to that location. Or you can do something more interesting.
You can actually install an extension, Chrome extension, from the Web store. I'm using a
(indiscernible) device devtools have to save for that. And my extension is installed and
configured. So that it mapped the particular -- the URL into the particular location of
my file system. Once I mapped it, everything else just happens automatically.
Let's go and -- go ahead and see if the changes are in place.
And here they are. So the changes were indeed persistent in the
file system and I was not doing anything for that.
[ Applause ] >>Pavel Feldman: Okay. Yeah. Thank you. So
now that's the -- that's the productivity story. We can jump into the source file, we
can change it to immediate feedback persistent, but it's really easy to provide such an instant
feedback when you are working on a desktop, because both your page and the devtools are
on the same screen in the same box. Wouldn't it be great if the same experience could exist
while you are working for mobile. Sam? >>Sam Dutton: Well, yeah, the good news is
that the devtools are available now for mobile. The devtools team have done a huge amount
of work over the last year to implement remote debugging in WebKit, and we are really pleased
to see this code being used across the industry now. Because there is no better way to -- to
get a really good impression of what your Web app is actually like out in the world
than to do remote debugging via USB on a real device that's getting real 2G, 3G, whatever
real connectivity. And, yeah, we would like to show you that right now, actually.
>>Pavel Feldman: Let me check it now. Internet connection?
>>Sam Dutton: We've got internet? >>Pavel Feldman: Yeah.
>>Sam Dutton: That's good. Okay. So it's really easy to set up. We go to the device. You need
to log me in here. >>Pavel Feldman: Okay, sure. I won't be showing
it to you. Sorry. >>Sam Dutton: So on the device in Chrome,
you need to go to settings. >>Pavel Feldman: There you go.
>>Sam Dutton: And from there you can go to --
>>Pavel Feldman: Wait, let me do it for you. >>Sam Dutton: Yeah. Okay. Get the right one
so I can see what I'm doing. In settings, you go to developer tools, then make sure
that enable Web USB debugging is enabled. That's all you need to do on Chrome on the
device. And -- and now we have installed the Android SDK on the desktop and then run port
forwarding, ADB port forwarding so that now we can look at Port 9223, which will show
all of the pages that are open on the mobile device.
We'll just open up YouTube now. And you can see what's going on there.
>>Pavel Feldman: Yeah. >>Sam Dutton: There we go.
>>Pavel Feldman: That's opened up. >>Sam Dutton: Right, so we have got devtools
there for the mobile device there. >>Pavel Feldman: Right.
[ Applause ] >>Pavel Feldman: Thank you.
So now let's see how it works. Of course, you can do simple stuff. So as I hover here,
you get areas in the screen of data. [ Applause ]
>>Pavel Feldman: All right. Or you can go vice versa, and Sam could you click on an
image here. Yeah. And here it is. The image that Sam has been clicking. You can see it
big in here. But that's simple, right, you can modify DOM here or play with the CSS,
but that's all simple, you can do it with the other tools as well.
But as Sam was saying, you could do some interesting things with the mobile handset. For example,
let's go to the network. While I'm on the network panel, I'm pressing
command R, to reload the target page. It usually reloads the target page for the devtools,
but in this case it reloaded the YouTube. What you can see in here is the precise network
information. That with the DNS connecting, sending, waiting numbers, for your cellular
network, for 2G, 3G, taken from the network stack, from this various device, so that's
the actual information in milliseconds came from this native network stack. Of course
you have all of the other information, all of the previews, responses, cookies, everything
that is available in the devtools, but again it's the mobile. Let's say you want something
more complex. You want to see how the cell phone performs on your tasks. So I'm reloading
the YouTube again, and timeline shows me not only network events but also the style recalculation
or JavaScript execution that happened on this very CPU architecture, different from my box,
at this very CPU this handset is running. Or even more fun stuff. Let's do some breakpoints
in here. I'm going to set a breakpoint. Oh, I have one on the mouse click. Can you click
it again? Here you go. You stopped on the breakpoint in the cell phone, all of the regular
devtools features are available here, so you can prettyprint, I can step through my execution
and everything just works. So that's all of the devtools features, full-fledged
developer tools running against the mobile. [ Applause ]
>>Pavel Feldman: Take it from there. >>Sam Dutton: That's fantastic stuff. So the
-- I guess looking at the other side of it, one thing that we've learned after kinda 12
months of remote debugging is that of course in lots of situations, it's most the best
thing to do to begin by doing as much as you can on the desktop tools. But, of course,
for that what you would need is really accurate emulation tools. And the devtools team has
been working really hard on putting a lot of those features into those tools, which
we will show some of that now, I think. >>Pavel Feldman: Sure.
>>Sam Dutton: We'll go over here. So we go over to YouTube. Let's open it over here.
There we go. So we've got -- yeah, we've got the desktop version there, and the remote
version over there. Now, I would like to go to the settings in the developer tools. And
if I go into there, and -- and let's -- let's go to the user agent panel there. You can
see the tabs now in the settings. And if I click on user agent, now what's -- it's a
Galaxy Nexus -- >>Pavel Feldman: It's a Galaxy Nexus, yes.
Does anyone have one? >>Sam Dutton: Yes, so I will select that now.
And -- and that's -- let's refresh that. You can see we've got a really accurate representation
of what it actually looks like on the mobile device. And let's just -- in fact, this little
button here, I don't know if you can see that, it kind of swaps from portrait to landscape
mode pretty handy. So if I click that and just zoom out again, you can see now again
we have got a really accurate representation. One thing that we've got here, you know, it's
not kind of faking it. You will be able to use Media Queries for this and it will work,
so, yeah, really handy stuff. I will turn that off.
[ Applause ] >>Sam Dutton: And obviously another crucial
feature when you are trying to build for mobile devices is touch. And if we go to this example,
it's -- it gives us, you know, the ability to see how touch works. The only problem being
-- >>Pavel Feldman: Override. You --
>>Sam Dutton: Sorry, I left the override on there.
>>Pavel Feldman: Yeah. >>Sam Dutton: Okay, just refresh that. And,
yeah, so what you can do here is use touchevents, but, you know, it doesn't work obviously.
What we have in the tools is the ability now to emulate touchevents and you can set breakpoints
and so on, there we have it. I'm using touch there on the desktop device.
So, yeah, really handy tool. >>Pavel Feldman: So you were just dragging
your mouse and it was emulating the touch. >>Sam Dutton: Right, yeah, that's good stuff.
So, um, I would like to just kind of I don't know shift focus a little bit now. We've talked
a lot about the parts of the tools that make your life easier as a developer. Also, you
know, thinking about the users of your apps. What's in it for them?
And, you know, particularly in this world we have now where users really come to expect
from Web apps these, you know, these new features that really push the limits of the CPU and
GPU and memory and so on and, you know, in that context, in particular, how do we -- how
do we measure responsiveness? You know, this idea like what is it, how do we measure it?
And luckily, we have some tools for that. I was thinking in particular, you know, a
website you may have seen called HTML5rocks. It's got a really nice interface, really great
content. But we've noticed some, you know, just slight stuttering, it's hard to see here.
But some slight stuttering with scrolling on the page and, you know, the thing was coming
at that problem -- you know, there are a million things it could have been. And what I wanted
to know from Pavel is how do we approach that problem where you really kind of have no idea
where to start. So, yeah, I thought maybe you could give us
hints there. >>Pavel Feldman: Yeah, of course. So you start
with the timeline when you don't know what's happening in the page, especially if you have
performance issues in the page, you start with the timeline.
So let us record a timeline in here. I will do devtools to get a bit more real estate
in here. And in the timeline, I am pressing record the record button and I go to the page,
and I scroll it a bit, and then I go back and turn off the recording. So what I can
see here, let me zoom into a window here. What I can see here is a lot of events are
happening within the browser. And timeline not only shows us the JavaScript events, it
shows all of the native events, styles, painting, everything that happens in the browser. While
hovering over these elements, you can see what is actually taking time. Yellow is scripting,
blue is loading, we didn't have any and green is painting. So this picture gives you a very
good understanding of what's slow. >>Sam Dutton: Yeah. That's good. That's good.
I mean, the only problem is, you know, I remember when I first saw this timeline thing I thought,
wow, that's lot of information. But it's kind of useless, you know. It's like where do we
go from there? It doesn't really give me a picture of what's happening each time there's
a slowness -- >>Pavel Feldman: I give up. So we've gotten
exactly this feedback from you and we thought we need something better. And with this version
of Chrome we are introducing a new frame mode of the timeline. Let me zoom into a couple
of frames. So with these frame mode in the timeline, we are defining a new term, a frame.
And the frame is the amount of time that the browser needs to update the screen. It includes
everything. JavaScript processing, recalculation of the styles, painting, everything is happening
within the single frame and then your user sees the picture.
You can see the same nice color coding in here. Green is paint, purple is layout, styles
and the yellow is scripting. But more importantly, we set a baseline to
you. And this baseline is 60-hertz. 60 frames per second. That's what browser expects from
you. You need to generate 60 frames each second. It gives you only 16 milliseconds per frame.
That's the same vsync signal that we've been talking about on the keynote. Now, if we look
at this very page, we can see that the frame was taking, in fact, 45 milliseconds.
And it is above the baseline of the 60 frames per second. This solid line in the middle.
So it's not JavaScript in your case. It's not styles. It's the paint. You must be painting
something very beautiful. >>Sam Dutton: Yeah, yeah, no I know.
[Laughter]. >>Sam Dutton: What I know is the culprit is
-- yeah, some there's some heavy duty CSS in there, a lot of gradients.
>>Pavel Feldman: Oh, I know! [Laughter] >>Sam Dutton: Aesthetic. Nice background image.
>>Pavel Feldman: I know it's nice, but it's slow. I removed all of them, and the page
still has that background. What's wrong? Okay. Let's inspect. Oh, are there are more.
[Laughter] >>Pavel Feldman: And those are the same. You
are using all over again the same gradients. >>Sam Dutton: Twice is good. [Laughter].
>>Pavel Feldman: Okay. Maybe it was making it slow. Okay. Anyways,
now that I've disabled everything and you can't really tell the difference, can you?
Let me go back to the timeline and start recording. And let me scroll here a bit.
Go back and stop my timeline. [Laughter]. [ Applause ]
>>Pavel Feldman: There's nice 16 milliseconds frame, thank you.
>>Sam Dutton: Yeah, okay, well done. >>> [ Inaudible - no mic ]
>>Pavel Feldman: Okay. Let's take it to the Q and A.
Thank you. >>Sam Dutton: Yeah, and if you want to learn
more about that stuff, after us there's the jank buster session.
It will go into more detail. >>Pavel Feldman: Right. So that was smooth
animations. Wrapping up, please measure performance of your animations and scrolling. Now we have
a good baseline, 16 milliseconds, you will know for sure, (indiscernible) smooth has
now a value, it's 60. Use this time wisely. Think as game developers.
Game developers don't have much time for a frame. Tools will help you narrowing down
the problem, whether it's paint or JavaScript. After you know the paint events and you need
to bisect those, regress, find where the culprit is.
For the JavaScript we have better tools. We will point you to the very line of the source
code that is updating the layout or recalculating styles. So you will know what is wrong.
And as Sam mentioned, in this very room, right after ours, there is going to be an extended
session on the frames mode for the timeline and the GPU team from Chrome is going to drive
it. So make sure you don't miss it. >>Sam Dutton: Yeah, great stuff.
Of course, Pavel was kind of cheating there. You know, you can always just delete stuff
to make a web app work faster. >>Pavel Feldman: You can? [Laughter].
>>Sam Dutton: That's true. But, you know, I mean we all know that these situations,
as much as you optimize everything, all your code, you get to a point sometimes where you've
got some code that is just inherently CPU intensive, long running.
And, you know, I was thinking about how to use the devtools to deal with that. And I
was thinking of -- you know, the prettyprint function itself. What I have noticed with
that is that, you know, it's obviously doing a lot of work but it doesn't seem to freeze
up the interface, so I have asked Pavel about how that works.
>>Pavel Feldman: Right, so it does use more than 16 milliseconds of time. We are using
WebWorkers to move the work off into the other thread.
>>Sam Dutton: Okay, Yeah. I mean, I always feel like I should use WebWorkers.
>>Pavel Feldman: Do you use WebWorkers? Not much, okay.
>>Sam Dutton: But I always sort of shy away from it, because I feel like they are hard
to debug, you know, like where do you start? >>Pavel Feldman: Oh, is it? [Laughter].
>>Pavel Feldman: Let's try that. As I mentioned we will be focusing on the WebWorkers, so
let me go back to the page where we were debugging devtools, for the devtools.
We will be interested in the source code. Do we have any? Well, let's reload.
Let's get some. Yeah, we've got some files. Okay. So here is the source code. As you probably
know, when you press this little button, it gets prettyprinted, really nice. And as I
mentioned, it happens in the worker. So let's try going ahead and debug it. I'm going to
the debugger sidebar, under the workers tab I choose to pause on start. So what it should
do, when the worker is created for your page, it should stop it before the very first statement
this worker executes. And we should be able to debug it. Let's try
it out. Okay. Now that we have three windows with
the devtools on the screen, I feel I must go over them again. So the one to the left,
is your Web page. It's just me, I have the devtools, sorry. One to the right is the devtools.
And the one in the middle is the devtools for the worker. [Laughter].
>>Sam Dutton: Got it. >>Pavel Feldman: Yeah, is that okay?
Right. So I can step through the execution here and I can see that I'm debugging the
worker. The worker is stopped. But he can scroll the page. So the page is not blocked
by the worker. So this is not the fake worker emulation using iFrames, this is the real
stuff, native workers being debugged. Now, of course you can use all of the debugging
functions in here or you can go and collect CPU profiles or take heap snapshots, do the
timeline for the worker or use console. This devtools window is working in the context
of your worker. And if you type window in here, there is no window and there's no document.
Who are you? [Laughter]
>>Pavel Feldman: It is dedicated worker context. So this is in fact the worker object.
Now, we support debugging workers, the dedicated workers and the shared workers. And the way
to start debugging shared workers is to visit Chrome Inspect. That's where all of the inspectable
properties of Chrome are represented, be it page or an extension or a background page,
application, shared worker, everything you can start from here. You click inspect and
you are brought to the right window. So that's the WebWorker story.
[ Applause ] >>Sam Dutton: I may even use them now. We
talked a lot about memory, but of course, there's always some kind of tradeoff with
performance. Well, or is there? We did some testing of Google Web apps, and
you can see on the graph here, the yellow line at the top there represents overtime
memory consumption, and the blue with a high level variance represents the measure of the
projection of latency. One thing we're finding with Web apps, I think this is a common experience
now, people are using Web Apps for much longer than they used to. We have users of Google
Apps like running them for days. So you need to be aware of that. What we learned was obviously
that there were memory leaks and that we could fix, and the most common source of that was
problematic -- in fact, it was problematic usage of event listeners.
>>Pavel Feldman: Okay. So I think we have some tools for that.
>>Sam Dutton: Yeah, indeed. >>Pavel Feldman: And we're going to explore
a simple example of the memory leak, and -- >>Sam Dutton: That's a lovely website.
>>Pavel Feldman: Yeah. So I'm going to the source, and let us see the source code. So
what it does is every time I click "say hello", it creates an element. Hello, there. And it
adds it to the result. But then in a second it just removed them all. But they all are
still here in this array. Let's see how the tool handles that memory leak case. But now
let's imagine we don't know it all and we start from scratch. Can you forget everything
that I've just said? I'm going to start recording the timeline,
and a number of clicks in here, and let me undock the timeline. Oops. And we are going
to look at the memory view for it, and let me face the window. What you can see here
is the heap graph. That's the memory your app is consuming at the top, so it's a bit
more than a megabyte. Then there is a regular timeline, and then there is the memory counters,
DOM counters, and event list counters represented in here. You can see that the number of DOM
notes increased from 18 to 24 as I was clicking, and the document is still alone, and there
are two new event listeners in here. If I click on the step, I will see that there is
an event associated with that. So every time it grows, there is some event in here, and
indeed the link, we can hover over and jump to the line that was creating that object,
of course, but more importantly we now know what user action is causing the leak. Now
that we know what is the problem, we'll find the actual location of that object. And for
that we turn to the profiler, and in the profiler, I'm going to -- let me go back to the page.
I'm going to take a heap snapshot. Let me say hello a few more times and take another
heap snapshot, and let's see what it is all about. So the heap snapshot is in fact the
snapshot of the JavaScript heap of running application. And the summary view that I'm
looking at is the summary for the heap where all the objects are grouped by their type.
For example, those are API functions and those are date objects. Those are Chrome events.
So everything is grouped in here. For each of the objects I can see -- for each of the
group I can see the object count, shadow size and the retain size, so its own size and the
size of the tree it is holding. Now, if I go to the second snapshot, that was taken
after my actions that are supposed to leak, I can compare it to the first one.
[ APPLAUSE ] And in the comparison mode, I can see that
there are 7 new objects. And if I hover over these objects, you get this hover card that
you got used to while debugging, and if I select this object, it will show me the retaining
trees for this object. Those are the guys that reference my object. And those are the
real cause of the memory leak. In this case, I have an array. And in its 13th slot there
is this paragraph element, and, you know these dollar zero that refers the currently selected
element in the elements panel, it also works in here. So from this panel you can jump into
the source -- into the console, into the running object and explore it there. Let's see what
is holding this array? It's a window. It's a global object. And the
property name on it is "holding", so if I do dollar zero, that's my window, and if I
do dollar zero holding, that's the array that was holding the paragraph element. So to recap
that, if you don't know where your memory leak is or where is the unbonded cache that
you're using, you should go to the time line, then you perform your actions and look at
the spikes in the DOM node counters. There is also garbage collection button that you
can press in the timeline to collect the garbage that should bring everything back to normal.
If it doesn't, this means you have a leak. Now that you have tracked down the user scenario
that is responsible for your leak, start using the heap profiler. You take a heap snapshot,
then you do your action, you take another snapshot and then you compare the two. And
once you've seen the leak objects, the objects that should not be there, look for suspicious
classes that you own the code, you know it. Then track the retainers in the bottom part
of the screen to track them to the global objects and you will see the exact path that
is leaking memory. There are more complicated techniques for finding memory leaks that are
more efficient such as three snapshot technology where you take three snapshots, then you look
at the third, and filter out everything that has been allocated between one and two, or
actually show everything that has been allocated between one and two, but it's a different
technique. It's more complex. It's beyond this session, but we are here at the Chrome
booth, so if you have questions there, make sure you come and ask them there. Okay.
>>Sam Dutton: Thanks very much, Pavel, really useful tools for dealing with memory as well
as performance. We don't have much more time, but I just wanted to mention a couple of more
features that have come into the tools now, really useful stuff, particularly in relation
to clientside story. >>Pavel Feldman: It's not the end.
>>Sam Dutton: Have a look at the features for index DB and App Cache. Have you seen
the web components? We have great tools for shadow DOM inspection, just go to the elements
panel and drill down into an element and you will see the shadow DOM compliance. It's great
stuff. My favorite thing of all, Pavel wouldn't let me demonstrate is source maps. These are
really easy to work with, you know, you use a tool like closure to minify your code, at
the same time you make a source map file, you put a link to the source map file in the
minified code, and that's it. When you use that code in the devtools, you'll see the
human readable version seamlessly in place. It makes life much easier.
>>Pavel Feldman: Come on. Come on. How can you love a feature like that? Here is my favorite
one. Here is the WebKit, right? Let us go back there. No, let's do Google. So in the
Dev Tools, right, I'm a developer, and where is everything in here?
Okay. And there's Google, and sometimes I am ambitious and I kind of think, okay, let
me change things here, and it will be a Google search, supersearch -- it didn't apply. Why?
They are fooling me. Come on. Do it again. >>Sam Dutton: That's weird.
>>Pavel Feldman: Yeah. Oh, it wasn't title. Okay. Sorry. I'm feeling very lucky. Are you
working for me? Okay. Good. Then I have more ambitious, I
think. Okay. So that color is not -- I want a red one. And then I think, okay, this Nexus
7 is really cool. I actually go and list the font size for it, and do the shift up. Yeah,
and I think, okay, so this is enough clutter here, right?
I need to get rid of it, and go and delete it all, and you know what, the search field,
I don't like it either. I'll just delete it all.
>>Sam Dutton: That's too complex. >>Pavel Feldman: Come on. And then I think,
okay, I've done a lot -- why can't I delete it? Come on, Google, where is it?
Yeah. And I think, okay, that's enough, and then I calm down, I think I like it the way
it was, and I press command C and things are undone, or I press shift command C and things
are redone. So we have the complete undo-redo stuck in here that is more importantly retaining
the identity of the nodes, so when I'm deleting nodes or recreating nodes, those are the same
objects, and your JavaScript points there and your program remains functional with that.
So that's a cool feature. [ APPLAUSE ]
>>Sam Dutton: Go back. Go back. Come on, while you're there, someone asked for this, do command
-- what is it, command plus. >>Pavel Feldman: No, I won't show you. I'll
show you the question mark. The question mark is where you get all the shortcuts to all
the features that we have, the ones with the shortcuts, including the ones that go to file,
go to line, and goes to your font size. >>Sam Dutton: Okay. So, yeah, we've been using
Chrome Canary today. Would recommend if you're using the devtools a lot, that you give Chrome
Canary a try, you get all the newest features and also you can give us feedback on how you
would like to see the devtools in the future. And if you've never filed a bug, you know,
today's the day, new.crbug.com. Go there to file bugs, make feature requests, anything
Chrome related particularly with the devtools, do it now, yeah, that's the place to go for
any of you stuff. So, yeah, that's it from us, thank you very much. Indeed.
[ APPLAUSE ] >>Sam Dutton: We've got about -- yeah, about
7 minutes for questions so if you would like to ask questions, come up to the mics in the
aisles there. >>> I thought of one more question, you're
taking requests for improvements to devtools. Remote debugging is really cool, but it doesn't
work when you're offline, because it hits app spot first. It makes it really hard to
do like mobile development on an airplane. >>Pavel Feldman: So I can give you advice
how to work around it, and then we'll fix it. So the workaround is to save that page
that is served alt app engine, and it's just a Web app, and you save it, you open it, and
you point to your Chrome instance or your mobile instance and it will work. No need
for a cloud there. Okay? >>> Is there a way to see the packets in the
Web socket? >>Pavel Feldman: Yes, in fact you can see
the packets on the Web socket. And let me show it to you, so that's -- okay.
I'm going to use a -- we are using those, right, for the devtool itself, where are you
-- where are you? Okay. So I'll need to do devtool on devtool
on devtool, but that's probably fine. You got used to it. And in the network, I don't
need to record. I'll just do some stuff. And you should see the packets in here, and if
they aren't, we just can't find them, so the idea is that you can see the resource responsible
for the Web socket packet in here, and in the editing part of this screen, you will
see Web socket frames tab. I can't show it to you right now, but it's there, and it is
going to be stable in Chrome 21. It's a recent feature.
>>Sam Dutton: And another? >>> Hi, thank you guys for the presentation.
It was real cool. So I have a question: Is it possible to simulate the http request that
like that made from UI, or, you know, you click a button, you have a bunch of requests,
is it possible to simulate a bunch of them and override some headers, override a script
that can do it. >>Pavel Feldman: Not yet. XHR replay simulation
is very high in our to-do list, so we are going to make it soon, but it's not there
yet. >>Sam Dutton: Yeah, lots of people are asking
for that. >>> Thanks.
>>> So do these techniques -- I mean the kind of examples that you showed were a little
bit, you know, contrived obviously for the demo, but let's say Gmail, does Gmail use
the Chrome devtools in the same way that you're doing it or do they use different tools or
do they have different techniques in how they use the tools, you know, for debugging and
just working with that system, because there's literally, you know, dozens if not hundreds
of events happening per second in the timeline, the heap snapshots will have, you know, tons
of different things, does it scale to something at that level?
>>Pavel Feldman: Gmail is our best in-house client so we're working with them a lot. These
three snapshot techniques with the heap profiling was in fact -- those were discovered while
working with the Gmail team while they were hunting their memory leaks. They're also using
timeline and, of course, they're using RD bugger.
>>> So it does. >>Pavel Feldman: Yes. Of course.
>>> Okay, thanks. >>> Hi, is there a good way to inspect, edit
CSS key frames, the CSS animation key frames? Because you can -- you can see the define
animation, but I want to see the key frames, edit them, and then look at performance issues.
>>Pavel Feldman: So the best you can get is just jumping to the source code and editing
them there. Everything you do in the source code is immediately reflected in the screen.
>>> Okay. >>Pavel Feldman: But there is no structural
editing for the key frames and for media queries yet.
>>> Okay. And then is there a way to trigger them, force them to rerun in a performance
tracing kind of context. >>Pavel Feldman: Of course. You can edit everything
in here, and then you just save, and then you go to the timeline and you perform those
actions and they will be using these new styles. Okay, thank you. Is the mobile debugging going
to be available on Chrome for IOS? >>Pavel Feldman: I don't know. We'll have
to check. So the remote debugging background is a part of WebKit, so the code is there.
I believe there is a way to remove the debugger IOS devices. I don't know about the Chrome,
but I can find it out for you, and e-mail that, I'll send it back to you.
>>> Thanks. >>> And you talked earlier about getting below
60 frames a second, there was I think green, purple and blue were colors that you talked
about, and when you got below they all turned gray. What was the gray for?
>>Pavel Feldman: Okay, so here is the thing: The frame for us is everything that beginning
of the frames, and the gray that you saw above is the CPU activity that we do not instrument,
or it's an idle time. We are working on distinguishing between the two, so very soon we will be able
to say this is the CPU. It has been doing something. Or this is idle, the other tasks
are using it. So we are actively working on the timeline, on the frame mode, and it's
very first revision of it. >>> So if it's gray and it is the CPU that's
doing it, it's your app that is causing that CPU to spin up but you don't know why?
>>Pavel Feldman: Right, the spikes that we saw on the timeline, the gray one, transparent
one, were related to the CPU related to the switching in windows that I was doing as the
timeline was captured, so that was idle from your page perspective, because it was not
wasting CPU resources, so we will be able to cut that down soon and tell you that your
page is not responsible for it. But the picture that we show is accurate from the repaint
perspective, from the frame perspective, because something has been happening and your frame
has not been painted at that time, so there was indeed a jank in the repaint.
>>> Thank you. >>> Is there any plans on integrating a -- like
a testing framework into the devtool so, say, macros and assertions and these kinds of things.
>>Pavel Feldman: So we have a nice extensions API support where we add extensions for you
to be able to build your own panel in the devtool, or to react upon selection of an
element in the elements panel and such. We might extend those APIs if they are not sufficient
for achieving your goals. So we -- yeah, we are -- we are relying upon the third parties
to provide the functional like that. >>> All right, so there's no -- right now
on that direct like roadmap, there's no plans for a testing framework essentially?
>>Pavel Feldman: Right. Those would be done through the extensions at least at the first
page. >>> Okay, cool, thanks.
>>> I'm an engineer on the Google+ team, and first of all, I just want to say thanks so
much for these tools, I couldn't do my job without them. I mean, they're just a real
joy to use, they make Web development fun again. That said, we do obviously have a pretty
massively large JavaScript application and it's compiling files together and it's starting
across all that, so at least the search across sources made it easier again to figure out
where that JavaScript is coming from, but just loading it in and parsing it still is
pretty pokey, it's many -- I'm just curious how optimized that stuff is and how much you
think you can improve the performance even further when you have really large JavaScript?
>>> All right, so, by the moment Gmail was our like largest client, so whenever they
hit the limitation, they came to us and we fixed it, and please, do that as well, and
we'll be improving. So right now with the frame mode, we found that we have a lot of
junk in our own UI, and we do know a couple of little knocks related to the scale with
our text viewer. We are comfortable at about 100K lines. When it goes beyond we are not
that comfortable from the memory standpoint, but those are all fixable, so as we hit new
limitations, we are fixing them, so please provide your feedback.
>>> Okay, great. Will do. Thanks. >>Sam Dutton: Question from this side.
>>> We've been writing some code that runs on both node.js and the client, since node.js
using V8 does it have any association with this, or is this purely the clientside browser?
>>Pavel Feldman: Right. This is working against the WebKit based browsers primarily, so it
does not work against V8 or node. There is a solution that works against node, because
node supports -- exposes the V8 debugging protocol. There's a project called Chrome
devtool for Java that is an eclipse plug-in, and eclipse has indicated that can connect
both to Chrome and to raw V8 including node. I know that there is a fork of Web inspector
that works a pretty old font that works against node, and I know there are people that are
trying to implement wrappers around V8 so that they emulated the remote debugging protocol
that Chrome devtool is using so that we could connect there, but that is a work in progress.
>>> Okay. >>Pavel Feldman: So it's Chrome devtools for
Java and that is an eclipse plug-in. >>Sam Dutton: Thanks very much. I think we
better wrap it up. We've run out of time. Thanks again. Thanks also for the live feature
request earlier. We'll take note of that. Thank you.
>>Pavel Feldman: Thank you. [ Applause ]