24
Chrome DevTools Rendering & Memory profiling Open Academy 2013 Mate Nadasdi - Ustream, Inc

Google Chrome DevTools: Rendering & Memory profiling on Open Academy 2013

Embed Size (px)

DESCRIPTION

Google Chrome DevTools presentation about Memory and Rendering profiling on Open Academy 2013 (05.23).

Citation preview

Page 1: Google Chrome DevTools: Rendering & Memory profiling on Open Academy 2013

Chrome DevToolsRendering & Memory profiling

Open Academy 2013 Mate Nadasdi - Ustream, Inc

Page 2: Google Chrome DevTools: Rendering & Memory profiling on Open Academy 2013

WHY DO WE NEED A DEVTOOL?

Page 3: Google Chrome DevTools: Rendering & Memory profiling on Open Academy 2013

• Javascript is an interpreted language

• HTML, CSS debugging have to happen in the browser

• Logging, debugging network requests is essential

• Source and the final output could be totally different

• Performance optimization is becoming increasingly important,

especially on mobile

Page 4: Google Chrome DevTools: Rendering & Memory profiling on Open Academy 2013

Google is leading in new technologies

Native implementation and really fast support

Canary build deliver new features in really short intervals

Deep configuration possibilites

Early experimental access

Rendering / Memory Profiling tools

Why Google Chrome?

Page 5: Google Chrome DevTools: Rendering & Memory profiling on Open Academy 2013

Red - Yellow - Blue?

Chrome channels

• Stable (Releases in every 6 weeks)

• Beta (1 month before stable, weekly releases)

• Dev (twice weekly)

• Canary (daily)

Chromium

Page 6: Google Chrome DevTools: Rendering & Memory profiling on Open Academy 2013

Rendering

Page 7: Google Chrome DevTools: Rendering & Memory profiling on Open Academy 2013

Parsing (HTML, XML, CSS, Javascript)

Layout

Text and graphics rendering

Image Decoding

GPU interaction

Network access

Hardware acceleration

Webkit / Blink rendering engine

Image Source: HTML5Rocks

Page 8: Google Chrome DevTools: Rendering & Memory profiling on Open Academy 2013

From source to display - The ordinary way

HTMLHTML Parser

Attachment

CSS ParserStylesheets

Layout

Shared bitmap

DOM tree

CSSOM tree

Render Object tree

Render Layer tree

n..1

Page 9: Google Chrome DevTools: Rendering & Memory profiling on Open Academy 2013

Layout (Reflow) & Repaint

Layout (reflow):

Parts of the render tree needs to be revalidated and node dimensions should be recalculated.

Repaint:

Some part of the screen needs to be updated because of a reflow, node geometric change or style change.

Page 10: Google Chrome DevTools: Rendering & Memory profiling on Open Academy 2013

Possible reflows & repaints

• DOM actions (Add, Remove, Update DOM nodes)

• Hide/show with display: none (reflow & repaint)

• Hide/show with visibility: hidden (repaint only because of no geometric change)

• Adding stylesheet dynamically

• scrolling, resizing the window

• DOM queries can cause a reflow too

• offsetTop/Left/Right/Height

• scrollTop/Left/Right/Height

• clientTop/Left/Right/Height

• getComputedStyle

Page 11: Google Chrome DevTools: Rendering & Memory profiling on Open Academy 2013

Tips to minimize reflow & repaint

• Try to minimize layout cost with smaller subtree modification

• Detach DOM nodes before huge manipulation

• Do not change styles one by one (use classes instead)

• Group DOM read and write actions to let the browser optimize reflows for you

(DOM queries flush the browser’s queue of changes)

• Cache queried values, do not query them in every case you use it

Page 12: Google Chrome DevTools: Rendering & Memory profiling on Open Academy 2013

Compositing, You Are Welcome!

• There are more GraphicContexts

• New tree in our forest, Graphic Layer tree

• Composited RenderLayers get their own backing surface

• Upload painted bitmaps to the GPU as textures

• 256x256 tiles

• Different thread for compositing

• Much cheaper then paint

Page 13: Google Chrome DevTools: Rendering & Memory profiling on Open Academy 2013

Frames & Jank

• 60 Hz = We have got 16.66 ms only! ( 60 Hz = 1 / ~0,016)

• 60FPS is important, because 60Hz is average refresh rate of devices

• Jank: every time you can’t create a frame when your screen refreshes

• vSync - generating new frames only between screen refreshes

• JavaScript timers fails because of inaccuracy and different frame rates

• requestAnimationFrame is a good solution

20ms 20ms 20ms 20ms 20ms 20ms 20ms

Display refresh at 60 hz:

Our frame creation:

Page 14: Google Chrome DevTools: Rendering & Memory profiling on Open Academy 2013

DEMO! Rock with timeline panel!

Tips:

• Show paint rectangles: Use it to show expensive paints

• Show composited layer borders: Check your GPU compositing layers easily

• Enable continuous page repainting: Easy to find the most expensive layers

• chrome://tracing/: Detailed tracing system to track core functionalities

• Use JavaScript CPU profile with Flame chart to diagnose your yellow pieces.

Page 15: Google Chrome DevTools: Rendering & Memory profiling on Open Academy 2013

Memory profiling

Page 16: Google Chrome DevTools: Rendering & Memory profiling on Open Academy 2013

Javascript memory basics

Root object

• Top of the memory management system

• We cannot manipulate

• References global variables

Object variable

• Can reference other variables

Scalar variable

• number, boolean, etc

Page 17: Google Chrome DevTools: Rendering & Memory profiling on Open Academy 2013

Object sizes

Shallow size

• Memory held directly by the object

• It can be significant for arrays and strings

Retained size

• Indirect memory hold

• A size what will be freed if the object will be terminated

• For primitive types retained size equals shallow size

Page 18: Google Chrome DevTools: Rendering & Memory profiling on Open Academy 2013

Object’s retaining tree

Root

A

G

C

D

B

H

D object’s retaining tree is a graph, where paths are retaining paths from GC root to A.

Page 19: Google Chrome DevTools: Rendering & Memory profiling on Open Academy 2013

Garbage

Garbage:

Variables wich are unreachable from the GC root node

Garbage collection:

Finds all garbages and frees it’s memory to the system

Leak:

Object that still has retaining path accidently

Page 20: Google Chrome DevTools: Rendering & Memory profiling on Open Academy 2013

Possible leaks

• Closures

• Deleting DOM nodes without removing event handlers

• DOM could hold event listeners to objects wich are inactive already

• Cycles: two objects reference to each other when they retain each other

Page 21: Google Chrome DevTools: Rendering & Memory profiling on Open Academy 2013

DevTools workflow tips

1. Search for possible memory leaks with timeline panel

2. Use heap snapshots to capture object graph

3. Use all four views of the snapshot panel:

• Summary: An overview of our heap grouped by constructor name

• Comparison: Compare two snapshots

• Containment: Structured view of object graph

• Dominators: Find the most dominant points of the heap

4. Use the new Object Allocation Tracker in DevTools experiments

“Memory Lane with Gmail” talk about this new tool on Google IO 2013

https://developers.google.com/events/io/sessions/325547004

Page 22: Google Chrome DevTools: Rendering & Memory profiling on Open Academy 2013

DEMO!

Tips:

• Check counters during your interaction on the examined page

• Use GC force button to see how it impacts on your memory

• Use it in incognito window, because extension allocated memory will be listed too

• Ignore:

• line in parentheses

• lines in light gray

• GC collects garbage before snapshot execution

Page 23: Google Chrome DevTools: Rendering & Memory profiling on Open Academy 2013

Use Google Canary as it has all the features I have shown and more including lots of profiling experiments

https://www.google.com/intl/en/chrome/browser/canary.html

Page 24: Google Chrome DevTools: Rendering & Memory profiling on Open Academy 2013

Thank you!@matenadasdi

Special thanks to Paul Irish and Addy Osmani for reviewing these slides.