Web Inspector Session

We had a discussion and determined to change the UI to adapt for future development. We went to a tab based design.

It allows us to move forward with optional tools. Things like an audits tab that not everyone will need or use.

New UI direction works well now and in the future.

This year focus is on timelines tab. A lot of usability and performance issues. Reworking architecture to make it work like instruments. As we add more tools, we need a new backend/frontend design architecture that is more flexible.

We’re looking at memory profiling for things like heat maps. Track more memory use, not just JSC, but CPU as well.

Timelines a big focus this year.

A major request for inspector is knowing what you’ve changed. Keeping track of edits to the page. Maybe a changes tab, or integrated with the Resource tab. See diffs of changes on the resource. Know what you’ve touched so you can manually replay them. Exploring an extension API for web inspector. That work will start soon in WebKit open source.

Nikita Demo Experiment with Saam to extend code coverage profile showing a live code heat map of what is getting hit in JS code.

Code hotness visualizer. Highlights often run code. As I play the game it changes the background of the code subtly.

The hotness peaks at 900 calls. For now it is not relative per lines of code. Investigation revealed random distribution of calls per site. Not clear how to scale it.

We discussed letting you focus on a block if you only care about the heat scale there. These are range based, not just lines.

Myles Do you think the exec counts are a good proxy for runtime? No it is not.

This expands from the existing code coverage features. The goal is for better understanding of your code.

In the future it might be possible to cross-reference code into another profiling tool.

This is “basic blocks” of code with counts attached to them.

Demo using redblobgames.com/articles/visibility/

Wenson Is there a way to pause the updates? Data from a certain range of execution might be useful.

Joe Could pause the debugger.

Nikita No instrumentation for that.

Planning to disconnect type profiler from: code coverage (dimmed out lines), data type highlights and code hotness visualizer.

Tim One thing our intern did is a new visual style sidebar. Useful for designers unfamiliar with CSS, or if you forget a specific CSS property.

You can use the Option key to get the more uncommon values for the property. Things you don’t always need, but things that you might need from time-to-time. Once you have use one of the rare values, the menu is populated with the rare values automatically.

One cool thing is that you can right-click on “This Element” at the top of the visual styles sidebar and copy all the rules that it generated.

Lately we’ve been working on architecture of the web app to reduce stuttering when it renders. Matt Baker has been working on

Before we would do a force layout and something was updated and we need to update it.

Now we have a tree of views that can be dirty or not. If it has children that are dirty then it can schedule an update with requestAnimationFrame. We’re still doing dumb things forcing layout. Our goal is smooth buttery 60fps. This will help us isolate forced layouts. There’s also numbers on the backend. Right now it looks bad, and we don’t know the cause. Our goal is to get that information visible. Now that web inspector is in its own process it is easier to do this work. We can now more accurately measure these things. All of this is going on behind the scenes.

We currently have an instrumenting profile named legacy profiler for 5 years. replace with sampling profiler now that JS is high speed JIT-ed. The profiler slows down performance immensely. Replacing instrumenting profiler with sampling profiler will get us closer to 100% compared to the original approach. It has a big impact on the page performance while recording a timeline.

Part of this is to get performance numbers in timeline that mean something useful.

If we collect too much data we can’t put it in the timeline. Sampling allows us to control the amount of data and prevent performance issue.

Joe will be working on memory implementation where we’ll use the GC to do heap snapshots and start showing that is the timelines. So you know when you have global objects as roots holding on to things.

Jon Honeycutt Web Inspector is a heavy web app.

Tim Most of the performance slowdown in debug builds is debug info, not web inspector. Some impact is forced layouts.

Geoff that problem isn’t inevitable. We can fix it. 3 things I’ve seen:

• there are bad things we used to do for performance code to scan every resource intrinsically slow terribly slow in debug build. Regex interpreter compared to regex JIT.
• Sometimes there are things slow in debug builds because of assertions or stuff. Those are fixable.
• Some things in web inspector in release build will hang for 2-10 seconds. If you see that in debug build it’s like 30 seconds. You might conclude release build useable, debug build unusable. It is fixable.

As a general principle in WebKit and it is too slow in debug build, we can and should fix it. If debug build bots are 4 times slower than release builds, then we know we need to fix that.

All you lose is inlining and register allocations.

Bot tests is 16 mins in Release on a MacMini, 37 mins on debug build.

Alex A lot of checks on hash tables that we do in debug build.

Geoff Those are constant time overhead. if we find some that aren’t we should turn those off by default.

Tim The slowdown log made me move off debug build. I don’t need the benefits of native code being debuggable all the time.

Geoff I have a comment on memory analysis. I used Andreas native memory analysis tool. He built it to help him in his job. My dream is to have tools that we use that we use the web inspector in these tools.

These are numbers that we could usefully give to web developers.

Footprint: useful to web devs bmalloc is like DOM + RenderTree + … libcmalloc is system memory for CoreText and OpenGL types of things JS JIT is JS code Images is images GC heap GC owned is bmalloc is a subset of bmalloc Other is a number you have to have for things you don’t know about Layers is likely WebCore layers or CoreAnimation layers

Tim I want to integrate some of that data.

Brian demo of the memory analysis tool