Who is this guy? – Biggest performance problems in .NET? – Why does this matter with JavaScript?

View Github Repository Open presentation in a new window

jwood803

See all presentation from jwood803

Who is this guy? – Biggest performance problems in .NET? – Why does this matter with JavaScript?

0 1

JavaScriptGCDemystified

Presentation to explain the JavaScript Garbage Collector.

On Github jwood803 / JavaScriptGCDemystified

JavaScript Garbage Collector Demystified

Created by Jonathan Wood jwood@wintellect.com / dotnetmeditations.com / @JWood

Go over what the talk will be about - Introduction to the JavaScript garbage collector with emphasis on the V8 engine and some tools and techniques on how to find and solve memory issues in your web application.

Who is this guy?

Mention about the company and how notable the founders are. Can also tell the story on taking the performance class that got me into learning more on performance. Also relate to WintellectNOW and the promotion/give-a-ways.
On demand training that features top instructurs. Perfect segue to mention the promotion.

Agenda

  • Why does this matter?
  • General Garbage Collector details
  • V8 Engine Specifics
  • Dev Tools Overview
  • Demo
Briefly go over the agenda to let everyone know what will be covered.

Biggest performance problems in .NET?

Memory ...memory ...and more memory Relate to the importance of performance implications in .NET. The same thing is happening in JavaScript. Down arrow for next slide!

Why does this matter with JavaScript?

Mention to how much JavaScript is being much more widely used and that functionality is getting put more on the client than on the server. Also make a special note about SPAs as well and say that with these, page refreshes are becoming much less frequent so items stay in memory much longer. Also, users can leave up pages going for days which leaves objects in memory.

How does memory work in JavaScript?

This is for the regular mark and sweep algorithm. Introduce the object graph, as well, in which all JavaScript values are part of the object graph.

Primitive Types

Down arrow here!

Numbers

var num = 12;

var num2 = 2.35;

Strings

var hello = "Hello, Carolina Code Camp!";

var sub = num.substr(0, 3);

Booleans

var isTruthy = true;

isTruthy = false; // Oh, noes!
These primitive types cannot reference any other values. The only container type is the Object. An Array in JavaScript is actually an Object that has numeric keys.

What happens during a GC in JavaScript?

A little look at how JavaScript will conduct a mark-and-sweep algorithm through the object graph.

JavaScript Object Graph

Graph is showing objects related to the root node. Objects can reference other objects, but values (scalar) nodes will only be as the leaf node.

Before a GC

To one object, the reference to the root node is gone. During the GC, this will get marked to remove from memory.

After a GC

GC was completed and the marked objects were cleared from memory allowing new values to be allocated to the heap.

V8 Engine Specifics

  • Generational
    • Young
    • Old
Down arrow here! Relate this back to .NET with the generational algorithm it has.

Young Generation

Down arrow here!
Young Gen is broken up into two semi-spaces equally sized - To and From. The To space is where all new objects are allocated. The From space is only used during a GC to sweep for live objects.
Going through the app and "A" gets allocated.
...and now "B" gets allocated.
...now "C" gets allocated.
...and "D" gets allocated.
"E" is now trying to allocate, but it's too big to fit in the space available.
"E" doesn't get allocated and a GC is triggered. The page is now paused from any other script execution.
The To and From spaces swap (interally, the labels to the objects are just switched). Now the From space will get swept and all live objects will get marked.
W"A" and "D" haven't been marked since it can't find a retaining path back to the root node and is considered garbage.
All live objects that have been marked is now copied back to the To space. This is where most of the time occurs during a GC.
The entire From space now gets recycled and ready for the next use.
The page now resumes and "E" is able to be allocated.

Old Generation

  • Infrequently collected
After a value is sufficiently old (how many young gen collections it survives - usually the standard is surviving two young generations) it is tenured into the old generation. Infrequent since most objects (around 70% to 90% don't survive a young gen).

How do I know I have memory issues?

  • Users
  • Crashes
  • Collecting data
Users - They will let you know when your site is slow. Listen to them! Crashes - The "he's dead, Jim" will occur often. Collecting data -

How to collect memory data?

  • jsHeapSizeLimit - Memory the JavaScript heap is limited to
  • usedJSHeapSize - Memory currently being used
  • totalJSHeapSize - Memory that has been allocated on the JavaScript heap (includes free space)
heapSizeLimit - The total amount that JS has access to. usedHeapSize - Memory that currently is in use by live objects. totalHeapSize - Memory that has been allocated so far, inclusing free space. This can be used for logging and even used for graphing. Information can be used to predict the "he's dead, Jim". Mention the caveat Chrome has that, even though each tab is a separate process, it can spawn a finite number of processes. So if there are a lot of tabs open, multiple tabs can share a process. If that's the case, the memory of the other tabs will be represented by the API call.

Chrome tools and techniques

How to get to the Dev Tools.

Timeline

Will show that there is a memory problem, but only the heap profiler can help identify where it is. Point out a few details of the screen, like the record button.
What the timeline looks like after doing a recording. Point out the items on the screen and add a few extras, like yellow color is all for scriping.

Heap profiler

Showing which one to use when trying to find memory issues.
Blue bars indicate objects that are still live at the end of the timeline, gray bars indicate objects that were allocated during the timeline, but have since been garbage collected. In the retaining tree, you'll notice two colors - yellow and red. Red is when the object doesn't have direct references from JavaScript to them, but are alive. Yellow nodes do have direct references from JavaScript. There should be a chain of properties leading from the DOM window to the element (i.e. window.foo.bar[2]).

Demo time!

Small messaging app that caches messages for better performance for the users. Only 5 messages should be cached at a time. MessageAuxData = message header. There would be a count of 6 (should be 5). Clicking a blue bar displays a diff of what's still live at that time. A grey bar should show nothing.
JavaScript can be dangerous if it's abused too much! Too much memory = very frequent GCs = unhappy users

Keep these in mind

  • How much memory is the page using?
  • Is the page GCing too frequently?
1. Using more memory can be detrimental to the page's performance since it will cause more frequent GCs which will cause the page a lot of pauses to the page to perform the collections. 2. This can be found out by using the timeline tool. A lot of GCs = allocating a lot of objects. The more memory, the longer the pause needed to do the collection. Leads to poor user interaction and users will be frustrated.

Sources

Thank you!

Email: jwood@wintellect.com Blog: dotnetmeditations.com / wintellect.com/blogs/jwood Twitter: @JWood

Presentation can be found on GitHub Demo code can be found at http://goo.gl/uI4D4