Changes between Initial Version and Version 1 of WebInspectorDiscussionFall2015


Ignore:
Timestamp:
Nov 12, 2015 11:17:02 AM (6 years ago)
Author:
Jon Davis
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • WebInspectorDiscussionFall2015

    v1 v1  
     1= Web Inspector Session =
     2
     3We had a discussion and determined to change the UI to adapt for future development. We went to a tab based design.
     4
     5It allows us to move forward with optional tools. Things like an audits tab that not everyone will need or use.
     6
     7New UI direction works well now and in the future.
     8
     9This 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.
     10
     11We’re looking at memory profiling for things like heat maps. Track more memory use, not just JSC, but CPU as well.
     12
     13Timelines a big focus this year.
     14
     15A 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.
     16
     17'''Nikita Demo''' Experiment with Saam to extend code coverage profile showing a live code heat map of what is getting hit in JS code.
     18
     19Code hotness visualizer. Highlights often run code. As I play the game it changes the background of the code subtly.
     20
     21The 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.
     22
     23We discussed letting you focus on a block if you only care about the heat scale there. These are range based, not just lines.
     24
     25'''Myles''' Do you think the exec counts are a good proxy for runtime? No it is not.
     26
     27This expands from the existing code coverage features. The goal is for better understanding of your code.
     28
     29In the future it might be possible to cross-reference code into another profiling tool.
     30
     31This is “basic blocks” of code with counts attached to them.
     32
     33Demo using redblobgames.com/articles/visibility/
     34
     35'''Wenson''' Is there a way to pause the updates? Data from a certain range of execution might be useful.
     36
     37'''Joe''' Could pause the debugger.
     38
     39'''Nikita''' No instrumentation for that.
     40
     41Planning to disconnect type profiler from: code coverage (dimmed out lines), data type highlights and code hotness visualizer.
     42
     43'''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.
     44
     45You 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.
     46
     47One 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.
     48
     49Lately we’ve been working on architecture of the web app to reduce stuttering when it renders. Matt Baker has been working on
     50
     51Before we would do a force layout and something was updated and we need to update it.
     52
     53Now 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.
     54
     55We 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.
     56
     57Part of this is to get performance numbers in timeline that mean something useful.
     58
     59If 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.
     60
     61Joe 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.
     62
     63'''Jon Honeycutt''' Web Inspector is a heavy web app.
     64
     65'''Tim''' Most of the performance slowdown in debug builds is debug info, not web inspector. Some impact is forced layouts.
     66
     67'''Geoff''' that problem isn’t inevitable. We can fix it. 3 things I’ve seen:
     68
     69* 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.
     70* Sometimes there are things slow in debug builds because of assertions or stuff. Those are fixable.
     71* 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.
     72
     73As 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.
     74
     75All you lose is inlining and register allocations.
     76
     77Bot tests is 16 mins in Release on a MacMini, 37 mins on debug build.
     78
     79'''Alex''' A lot of checks on hash tables that we do in debug build.
     80
     81'''Geoff''' Those are constant time overhead. if we find some that aren’t we should turn those off by default.
     82
     83'''Tim''' The slowdown log made me move off debug build. I don’t need the benefits of native code being debuggable all the time.
     84
     85'''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.
     86
     87These are numbers that we could usefully give to web developers.
     88
     89Footprint: 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
     90
     91'''Tim''' I want to integrate some of that data.
     92
     93'''Brian''' demo of the memory analysis tool