[MUSIC]

I'm gonna talk a little bit about a topic that I think is, is important, but

not covered often and that's Browser Memory Leak testing.

So, Rolph already introduced me.

I won't spend any time here.

I am, I do love JavaScript.

I'm very happy to work with it all day,

every day, at appendTo with some great people.

And I wanna ask you a question, and feel free to type in Chat if you'd like.

If I were to tell you that your app has a memory leak,

what's the first word that comes to your mind?

By I, I could be your manager.

I could be your customer.

I could be your, significant other.

What if someone told you that, that you had a memory leak, how do you feel?

Well, I've had these feelings in the past, as well, and

I'll share a couple of the ways that I felt.

Denial is one, one choice.

Might say things like, well, maybe they just didn't wait long enough for

it to be recovered.

Maybe it's the extensions,

they must have some extensions installed that's holding onto things.

Maybe some sadness.

Sadness that I, that we didn't catch it.

Sadness that we didn't, didn't understand why it was leaking.

And ultimately scared, you know,

how do we figure this out, how do we move on how do we take care of this leak?

So my goal today is to discuss a little bit about the basics of

Browser Memory Management.

Talk about some real life situations that I've seen both in client projects and

in, in code that I, I've reviewed for others.

Talk about some of the tools that you can use.

Things that you can really zero in on what that, that memory issue is.

And finally, you know, the idea is that hopefully after,

after you leave here today you can take a look at some of your projects and

see if you have some of these situations going on.

So just for today what's our definition for a Memory Leak.

This isn't something I,

I copied from somewhere, this is just my definition for today.

It's temporary memory allocation that the browser's holding onto longer than

is necessary.

So you've created some variables.

You've created some objects.

And, it seems like everything is good.

You seem like you're done with them, you don't need them anymore.

But, as your application goes on you may find that it's actually causing problems.

As, as the longer that your browser's open.

So in my opinion, why is this more common today than ever?

Well, the rise of single-page applications, I think that, that most

people are pretty familiar with, with how that has come about in the last few years.

Some of that is due to some of the great frameworks that are out there,

like Angular, Knockout, and Backbone, and Ember, and, and the list goes on.

In single page applications, typically,

your browser is staying on that same page for a long time.

It's communicating with a back end via API calls.

So, by not navigating from page to page,

you're, you're not giving the browser a chance to really get rid of some of that,

that memory that may have, have been hanging around but not causing problems.

And part of that is, is these JavaScript heavy front-ends,

it's more common to be doing lots of things in JavaScript.

We're doing things with audio and video and canvas and

SVG and there's great libraries out there that help us

do some really incredible things in the browser these days.

And, and as part of doing that [COUGH] there's so

much code out there on GitHub and other sites, libraries, plugins, frameworks.

One of the big places that I've seen leaks is really in trying to

integrate all these things together.

You have a problem, you find a plugin that seems great for

the situation, you pull it in.

But the way that you're using that plugin may not be quite how the author intended.

Or maybe the way that you're trying to combine things together can contribute to

memory leaks.

So a little bit about how memory is, is recovered in the browser.

We'll talk about garbage collection, it's not just browsers.

There's other environments where garbage collection is,

is the way that memory is managed and it's very automatic so.

In general you don't have to do something to say to that, hey I'm done with,

with that memory.

In garbage collection when, when you don't have references to things any longer,

when, when nothing can reference it browser is free to,

to clean up that memory.

So you don't have to do anything specific to make that happen.

Now in older browsers,

a technique called Reference Counting was used as recent as IE6 and IE7.

And what, what this is,

is it kept track of how many times an object was referenced.

And when that went down to zero, then right away the browser could say,

I can clean that up.

Well there were situations where that failed, especially in circular references.

Just have an example there where we have an element.

And there's an object that points to that element.

And that element has an expandable property that points back to that view.

And this, this is a pretty naive case but

it, it would cause that circular reference that would cause a problem.

Because both of those, both that object and

that element would have a single reference just to each other,

even though nothing else might be able to reach them at that point.

So modern browsers implement a technique called Mark and Sweep.

And there's obviously a lot of complexity to how each browser

actually implements it.

But the idea is that periodically a garbage collection pass is made and

the mark part is that it, it, it goes from the root.

So that would, might be your Window object it,

it might be the DOM tree the various things that are considered roots.

It would go from there and find everything that it can reference tracking through,

traversing through the different trees and leaves.

And I would mark those objects.

And then I would take a sweep through all of the memory allocated and

I would be able to remove anything that was left over.

The diagram that I have here is from the Chrome Dev Tool documents and

I have a link to that here.

It describes how to use some of these tools in Chrome at least.

And it shows a Root Object here.

It shows some references, so I'm able to traverse down into these references.

And in this case this 9 and 10 are no longer referenced.

Maybe at one point 5 had a reference to 9,

but at this point it doesn't so, it would be able to mark all of these.

And then, when it went through in the sweep pass would be able to say, well,

9 and 10, are no longer needed.

Now, if 9 and

10 had that circular reference that we talked about in the previous slide,

it wouldn't matter because, nothing from the Root, can actually touch them.

So it doesn't matter if they reference each other, they still would get

cleaned up, because there's no way to get to them from the Root.

So as far as tools go in my opinion Chrome has

the most comprehensive tools available to look at memory leaks.

IE11 however though,

has some really nice functionality going on in their memory profiling view.

And we're gonna look at both Chrome and

then and then some screenshots of how IE11 looks as well.

In Firefox, there's an about:memory view that can give you heap dump and

let you do garbage collection from there, force it.

There are some other extensions and scripts which I link to here,

if you come back through Presentation One later on you can take a look.

Safari it doesn't have a built-in tool to do it at this point,

but they do suggest using the Instruments Tool DevTool in,

in Mac OS X and here's how that looks.

There's a template for leaks.

You can actually attach it to the Safari browser or an iOS simulator, or

even an OS X application and, it can give you things like a heap dump.

Although it's, it's much further away from the JavaScript, so

it, it's a lot harder to interpret.

[BLANK_AUDIO]

So, let's talk about Chrome a little bit.

In Chrome there are three different tools that can, you can use to investigate

memory leaks, and I'll talk a little bit about why you would use each one.

First I'm gonna show some screen shots and talk about it, then I'll, then

I'll actually jump into an example where we can look at, at each tool in action.

The first is the timeline view,

and there's a number of things that you can capture here, but one is, is memory.

So, I can check this Memory option and I can hit Record and it will let me,

over time, see how the memory is growing in my application.

And so the memory time line is really designed as far as from a memory leak

perspective, it's designed to help you determine do I really have a memory leak.

I may be, the memory may be going up, but then eventually it may go back down.

It may just take some time.

So that memory timeline,

it's not as much to dig in as far as what's what's that memory.

It's more about do I have a memory leak.

This garbage can here you an actually force a garbage collection and

after you're done recording.

And again I'm going to jump into the tool in a second here I just wanna talk over

the screen shot.

After you're done recording you can actually look at a snippet of time here

and then you can dig into that a little bit and see, for example, they used

JS Heap during this time period, is going up and up and up, which doesn't look good.

The second tool is called the Heap snapshot, and

that will really be a dump of the entire heap at that time.

Now there is a lot of other stuff in there besides just the things you have created.

There is a lot of things that the browser uses, so it is somewhat

challenging to navigate, so in some ways you, you want to have some clues as far as

what to look for, you want to be able to search for some of the art data.

You want to be able to understand what, what applies to your application and

what doesn't.

The Heap snapshot will let you do comparisons between two Heap snapshots, so

that's what we're showing in this particular screenshot.

it, in this case it's showing you that there's some new objects being created.

You know, you could see if ones are being deleted, being removed.

You can see the size of some of those objects.

So the Heap snapshot's really that nitty gritty, you can really dig in and

see everything that's currently in the, in the Heap memory.

And then a newer tool in Chrome that's actually quite interesting is,

is called Record Heap allocations.

And, it's kinda like a combination between the memory time line and

the Heap snapshot.

So, it let's you record over time,

and it will be taking a series of snapshots as it goes.

And, the gray, the, the, I'll talk about the blue bar.

So, the blue bar, any time memory is allocated,

you'll see a blue bar indicating how much memory was allocated.

When that particular memory is recovered, it will turn gray.

So you can see all these gray bars in the past here.

That's all memory that was allocated, and then recovered.

So this, this is a view that really lets you dig into

things that happen over time in your application.

Maybe you're going through a work flow where you perform some action and

then you go back and then you perform that action again.

And you would expect to be at a steady state of memory.

The things that you, the, the, the objects you created while performing that

workflow, you would expect them to be recovered.

And this will help you understand when things are allocating and what's left.

So again, I can, I can actually zero in on a period of time here.

So I'm gonna jump into a quick example here.

And I bumped up the font of the DevTool, so

hopefully that'll, that'll come out clear.

And I'm gonna pop into a sample where,

really, memory is being allocated again and again over time.

And I can come in here and make sure memory is captured.

If I want to I can filter out some of the noise.

In this case I don't care so much about rendering and painting in, information.

I can hit Record and we can start to watch it.

It gives me some interesting information about timers being fired.

In my case what's happening is, is every second a timer's being fired and

it, and it's adding some objects to an array on the page.

So I can't actually, I can actually dig into one of these timers and

understand exactly, you know,

where that function is that's being called, which could be useful at times.

But what I can see here, is that memory is growing, and growing, and growing.

And mem garbage collection,

depending on the rate of that you're actually creating objects.

The garbage collection happens fairly often.

So it's not like you're generally going to have to wait seconds and seconds for

it to happen it's, it's happening quite often.

So I'm gonna stop recording here, and we can see the memory was going up over time.

Again, I can dig into an area of time on there if I want to.

Here, I can look at just a particular point in time.

And, I can do things like look at the number of DOM elements that are coming and

going in the page the number of documents, number of event listeners.

And then the use JS Heap in this case is what’s most interesting to us.

So it's going up and up and up.

So I send Marie a timeline again generally used to

used to identify that, hey I do have a memory leak.

Let's look at Heap's snapshot now so

if you go over to the Profiles tab of the DevTools you can take a snapshot.

And, I'm actually, and then once you have taken a snapshot,

this button here will let you take an additional snapshot.

And I'm gonna do that so we can look at a comparison.

So, there's several different views, there's Summary Comparison and

Containment, there is an additional view called Dominators that you can get

to by checking a flag in the DevTools here.

It's not particularly important for us to talk about today.

But if, if you're looking for

where that view is, you need to enable it in the, in that dialog.

So, the summary tells us everything by what type of object it is, so

the constructor of it.

Things that are in in parenthesis are really system, system objects, and

you'll see a lot of stuff here, you know, float32array, things like that.

And a lot of it is things the browser has created, the browser is using,

it's not stuff that you specifically decided to use.

In this case, I'm gonna dig, I'm gonna filter it by my_data.

And I can see that there's 20 20 objects here.

I can see the shell size that's, that's just how much each of those objects takes.

The retain size is that object and, and all of its references.

So really, if it gets removed, that all of that memory would be recovered.

So I can dig into my data and

I can look at, at each one of these 20 objects and see why it's being retained.

The distance here is that distance to that root.

So remember that diagram this would be the distance to that red,

that, that initial root.

And if I look a little bit in here I can see, that there's a window.current data

property and that's why this my data is being hung onto.

If I look at this one I can see see the, the distance now is three.

It's actually the previous property of current data and if I look at this one,

it's the previous property of the previous property of current data.

So I think you can kind of see what my problem is here.

If I jump down here, I'm probably gonna see a whole bunch of previous.

Yeah, so, you can kinda get an idea of why I'm having a memory leak.

My object's keeping track of its previous data, and

that's keeping track of its previous data.

So this, this would be how you can you use the Heap snapshot.

Now let's, let's look at Comparison a little bit so.

In the Comparison I can choose between snapshots, so

I'm not just two if I had many snapshots I could compare over time.

And I can see that there are eight new objects, eight new my data objects,

none were deleted.

And I can see some information about the size.

And then the final one is containment.

Containment is really those roots, remember we were talking about,

about the Root.

The ones that you're gonna want to concentrate is the Window Objects and

the DOM Trees.

There is some other stuff that's really more specific to the browser like

the GC Roots has, has other stuff in there that is not gonna be as helpful to you.

But if you dig into the Window Objects you can,

you can see things like things that are, that are hung on that window.

So in this case it'd be Current Data you can see that jQuery has

actually loaded the my data constructor.

And then all this other stuff is just Chrome just

features that are added on the Window Object.

Another interesting thing to look at is DOM trees, so

you can look at the current DOM trees and then Detached is really interesting.

Cuz this is stuff that you removed from the page, but it's still hanging around.

And in this case we can see there's three detached elements.

And, I want to point this out cuz we're gonna see it a bunch later.

jQuery actually at, when you load jQuery it actually adds a couple of things

DOM elements that are, aren't attached to fragment here and a div, a div.

These are,

you don't need to worry about these, you'll see these if you're using jQuery.

They are, they're not growing, they're not changing they're just there.

So that is the Heap snapshot.

And we'll come back to that in some of the later examples.

The last piece that I wanted to show is, that Record Heap Allocations.

Again, this is fairly new, but it's pretty interesting.

I can see, again, memory being allocated.

It would turn gray if it was being recovered but it's not.

And I can see that over time.

It's taking little snapshots, little snapshots over time.

And when I stop recording this is the fun part is that I can actually dig into,

you know, a particular slice of time and

I can see exactly what was allocated during that time and what remains.

Now if I were to,

if I were to look between, you know, would show me nothing here.

And when I get into some, you could see exactly what was allocated.

And it, and it's really not what was al, it's what's left.

So if these were turning gray, and

I hovered over it's really nice cuz it would show you nothing.

If this was recovered, you would see nothing.

Which is, which is really nice.

Okay, so

that's a little bit about the three different tools that you can use and,

and we'll jump into, into those a little bit further when we get to the examples.

I want to talk about Internet Explorer 11.

This is that same, same cage profile that same page where you're

looking at we can see the memory going up.

Again when you're recording, you can take snapshots over time.

One thing that's really nice in, in the DevTools, and just to point out,

this is under this little camera thing it's the Memory View of

the Internet Explorer 11 tools.

One thing that's really interesting and it's not as easy to see, but

this is actually a screenshot of the page at that time.

I found that to be really helpful to just get a,

get a bird's eye view of hey, what was I doing at that time.

Was I on the home page, was I on the billing page, where was I?

So that's pretty nice.

It tells you the amount of memory that was currently the page was using at that time.

And then it tells you a difference between the previous snapshot,

difference in megabytes of memory, difference in objects, and then, you know,

plus or minus.

So that, that's a pretty nice view.

When you jump into one of those snapshots, you can again navigate through the,

the things that are out there by types that would be

similar to Summary in Chrome.

Here I can see it by the Roots which would be like that Containment View.

One thing that's really, that I found really nice in Internet Explorer is that

they have an option to turn off a lot of the, the stuff that the browser creates.

So when, when I'm looking at this I'm really just seeing the stuff that I've

added to the page which, really helps to cut down on some of the noise.

So, Internet Explorer has some, has, has kind of cleaned it up in some ways.

I do think Chrome has more features across those three tools, but the,

some of the, some of the little touches they have in, in IE11 are quite nice.

and, and you can do a comparison again between the two.

So I'm comparing two snapshots here.

I can see difference in size, that type of thing.

Okay, so now we're gonna jump into a few scenarios that,

that I've encountered that have caused memory leaks.

And generally, what I've done is try to

strip down these down to the simplest form that you could possibly have.

So, I'm, I'm not gonna include Angular.

Not going a lot of stuff to give you scenarios to,

in those scenarios that would just cause maybe some confusion.

I wanna kinda narrow it down to a situation where you have some content on

the page, and then you're gonna remove it.

So on a single page application, a lot of time what you're doing is you're rendering

some type of view, and then eventually the user wants to do something else.

So you clear it, and then you render something else.

And that's a case now, when I remove all those elements.

That's a case a lot of the times where there can't be a memory leak.

So, the first one I'm going to look at is related to Bootstrap.

So if you were around yesterday, you saw Bess's great talk on, on Bootstrap.

I'm sure many of you have used it.

And when using Bootstrap one of the features we

were using was the affix functionality.

And that allows you to sort of have a, a, an element that's fixed on the page.

And the way you do that is you can, one of the ways you can do it is just to

declaratively add some data dash attributes,

and that will signal Bootstrap to say, hey go ahead and affix this.

Then I have a button on the page that I'm just going to remove this element.

So again I'm simulating that single page app where we're gonna remove something,

put in some different content.

And I'm gonna jump back over to the example here bring up this affix and so,

you know, as I'm scrolling you can see this header stays in place.

A lot of examples are,

are really bare bones if not, trying to really style them or something.

But here when I clear out that content at this point I would expect hey

that table's gone.

And we can move on and render a different view.

So I'm gonna take a heap snapshot here, and there's,

there's a few ways we could look at this but I kinda like containment for this.

And I'm gonna jump into detached dom nodes and ouch.

Now I see that three, you know,

now this is that jQuery stuff I said don't worry about that.

So that's fine.

But I look at this, I see 7,025 detached dom nodes.

Wow, and when I drill into that I, sorting it by distance is quite helpful

because generally what's hanging onto it is the thing that's closest to the root.

And so I, I see there's an html table section element.

If I hover over it, I can see some of the properties on that element,

I can see it's got a fixed top on it.

And I can see it's that t head so indeed it's the one that I put that data-spy.

So when I look at this one other thing about the color coding, so

if you see an element that is coded in

red that means it has no direct reference to it from JavaScript.

If you see something in yellow that's really where the reference is.

So in this case there's no direct reference to this html, this, this T-head.

But there is something holding on to it.

So when I click on it,

when I click on one of these elements, I jump down in this retainer section and

that's where I can really drill in and see what's holding onto it.

I can see that it's a dollar element.

It's represented inside of a dollar element variable, I mean, a fixed object.

I can see that it's being used as the context for some function, and in this

case it looks like a jQuery proxy function that really forces the value of this.

And if I drill a little bit deeper I can see, oh there's some type of click event,

and okay there's a scroll and a click and a load event.

It sounds like window events.

And so at this point, you know, I personally haven't attached any window

events related to affix, I just put that data by and let Bootstrap do its thing.

So when we dug into it a little bit more inside the Bootstrap code.

We found that it was adding some.

That hammers to the window.

So the default target in this code happens to be the window.

And I remember Dave mentioned this yesterday in his jQuery talk.

You know, this is what's called a namespace event.

So scroll is the event, and the other stuff is

just a namespace which could help you actually remove it if you want to.

So that's what we found in the bootstrap code.

And just little, little reminder about how to remove events in jQuery.

Let's say I'm adding an event, and the name of the event is event and

the name space is our name space.

I'm adding some handler, some function I have.

There's a couple of ways that I could remove an, an event in this way.

If I just say $window.off("event.namespace"),

it would remove all for this event plus namespace.

So if, if, if I know that hey, this is my thing, I put my namespace on it, I've got

one instance of it or every instance I, I, it's okay with removing those events.

That's great, you can just use that.

If you do have access to the original function that was bound.

You could just to window.off with the event, and you know, that handler.

In our case with Bootstrap we really don't have access to the functions that

they use.

In fact, they wrapped it in a proxy call which means we,

nobody has access to that function directly.

And finally, if we don't include the event,

if we just say .namespace it would remove all events for that namespace.

And so again this was the code we saw in Bootstrap.

And we found that Bootstrap did not have a destroy method or,

or a way for us to actually remove those events.

So in our code, you know, we were doing more data binding so

it didn't look exactly like this, but in our code we

actually do an off without the event name, so it got all of the events.

And remove them ourself.

Like I said,

ideally, you know, ideally Bootstrap would, would provide that functionality.

You know, but, but they didn't so we, we had to take care of that.

And this comes down to sometimes,

like I'd said earlier, sometimes in these third parties that you're using you want,

the way you're using it is not necessarily intentional of the way it was created.

So so in this case we had to go into the library and figure out what it was doing,

then figure out what we needed to remove.

We found a similar thing when I was code reviewing a project with

sticky table headers, similar functionality, but it was adding

scroll resize events to the window and that was hanging on to the entire table.

In this case, the sticky tables headers had a destroy method that we could call.

That's a pretty standard convention in jQuery plugins.

Call that destroy method and that took care of it for us.

You know, if you're pulling in third party code it's good to think about not just,

hey, what does this thing do for me, what problem does this solve,

but is this thing gonna play nice in the environment that I have it?

Does it have a destroy method or a way to dispose it?

It's definitely something to consider when pulling in third party code.

So we call that destroy method.

That took care of it.

Scenario number two talk a little bit about Globals.

So won't spend too much time on it, but I think the,

the guidance that everyone has received regarding JavaScript for, forever now,

has been, you know, be careful about creating global variables.

As far as memory management, it's the closest thing to the root.

It's, it's not gonna go away.

If it's a global variable, or a reference by a global variable,

it's not going to get cleaned up.

So the code here is not too important.

Let's say I have some view object that, that I'm creating the instance of.

And I'm just doing this on a page or in a file that's referenced by a page.

When I look here, this MyView, it's gonna end up on a window.

And so is this app, so window.MyView, window.app,

those are gonna be on the window, they're not going to get removed.

So what can we do about that?

Well enter the IIFE.

Immediately Invoked Function Expression.

There are certainly other ways to handle it too,

but I'm sure that people have seen this in code or, or you're likely are using it.

It's a way to create a scope where, where variables inside of this are going to be

attached to the surrounding scope, which in our case would've been the window.

And so this is,

this is a function, and that function, we're gonna call it right away.

And if you wanna put your paren outside, you know, that's fine too.

It's, it's not important, some people it the other way.

So in our case one thing we could have done in that previous example,

we could have wrapped our code here in that IFFE novice my view in this app.

They wouldn't be on that window and

they would go away as long as nothing's referencing it.

You may be using jQuery ready block.

One of the forms of that would be, you know, dollar and passing a function in.

And, and that would, it's inside of that function as well,

so it'd still perform the same role that the IFFE would.

In the jQuery readies case,

it would just not execute that code until the dom content has loaded.

So in Blazon.

I, I know that you're familiar with Blazon now if

you've been watching the presentations, presentboldy.com.

I encourage you to try it.

It's a great tool.

A while back we found a, a.

Well, a bunch of dom nodes were leaking in Blazon, and

what it came down to was a tooltip library we were using called OpenTip.

And we were databinding against OpenTip, say,

tooltip next slide there's a bunch of tooltips in Blazon.

So any iconic button that you have on the screen, you can hover over it and

see that great tooltip.

And as we were navigating through slides we found out that, you know,

anything attached to these tooltips was just hanging around.

And when we dug into it more, what we found is that,

you know, it wasn't as complicated as it might seem.

Really, OpenTip was globally keeping track of all of the tooltips.

It had an array called OpenTip.tips and every tool tip created was added to it.

And there was no code to actually remove it.

It wasn't part of OpenTip.

Again, this comes back to the use case.

OpenTip didn't realize it would be in this scenario of a single page app

where you're coming and going with these tooltips.

So in our case, you know, the code here is not super important.

Just that we had inside of our custom binding.

We were creating a tooltip, and then later we actually added a disposal callback and

we had to remove the tooltip from Opentip.tips which was a global

array that was keeping all the tooltips.

Based on our binding we also had to know all term references,

but it's just a case where adding things to a global may be convenient but it,

it has other effects like hanging on, on to hanging on to that memory.

So you know again OpenTip probably should provide a way to remove that.

Okay, moving on to scenario three.

Closures.

Closures, closures.

Closures are.

We've already seen it some of the examples I've shown.

Closures really are one of the major sources of memory leaks.

And the thing about closures is this, we use them all the time.

We use them every day, we don't hardly even think about them.

We don't generally think, I'm creating a closure right now,

we're just creating functions and we're going from there.

The thing to remember is that from a memory standpoint it

really can carry a reference just like you're setting a property to some value.

If a function is using a variable that's outside of it's scope, you know,

that will be considered a reference.

[SOUND] You know, just a, just a brief example on closures here.

You know, I have this person constructor and

inside it I have a shoal message function and

it's alerting this message variable and the main argument that gets passed in.

And so I've created a new person called me and I can now call me.showmessage.

And so what's interesting about closures is that it's not just about what's in

this function, it has access to this message variable,

it has access to this name argument.

And not copies of them.

It's not a copy of message.

It's not a copy of name.

It can still access those, the actual variable.

So if I had another method that changed the message variable,

it would be reflected when that, that was called.

So I won't spend too much more time on closures,

but I do wanna really recommend the Scopes and Closures book by Kyle Simpson.

It's, it's online for free or you can buy it @getify if you've heard of,

of him through his Twitter handle.

It's part of his you don't know JavaScript series and it, it really is,

to me at this point, may be the definitive reference on, on scopes and closures.

I forgot my joke.

I was gonna say you know, I was gonna talk more about scos, closures.

But it's out of scope for this presentation Okay,

let's talk about a specific scenario.

Let's talk about our basic scenario here.

So I'm gonna come back and bring up

Flip back to the code real quick.

So, I'm using jQuery here.

We could be using raw DOM functions as well, but

I know that everyone is pretty familiar with jQuery, so

we're gonna use it to ease some of the burden of cross-browser support.

And one of the things you're told in jQuery, you know, cache that selector.

You know, selecting some elements.

Don't do that again and again.

Cache it.

So I created this variable dollar l.

It's just an element, my ID on the page.

And now I'm creating a click handler.

I'm updating the text when you click on it,

and when you, when you click the clear button, and I'm removing it.

So I had to use dollar l a few times.

Seemed like caching it was a good idea.

but, let's see, let's see what happening here.

So I open this up, and I'm gonna clear that, so I'm removing it.

I'm just taking a snapshot.

And let's go into, detach DOM nodes.

Again I see my jQuery stuff that I'm okay with, but here I have a div.

If I hover over and I can see, yep that's my testing div.

It's being held onto for some reason.

And if I look down in here I can see well it's the dollar l variable,

inside of some function.

And what is this function?

Well, it's that dollarl.remove from there.

Okay, so if I flip back over, I can see.

Yeah, you know what this, this event handler is still attached to that button

and now that dollar l is being hung onto, and since it points at that

jQuery wrapper to the element, that element can't actually go away.

So one tip here.

You know if I, I, I can actually name functions.

So even in a like a function I've created anonymously here, I can give it a name.

And that's really helpful in stack tracing and, and tools like this.

So here's an example, I'm going to do this again.

But I've named that function.

And let's just take a look quick at that snapshot.

Called the containment and detach DOM nodes.

It's and look at this div again.

See now it doesn't say anonymous function.

Now it says my remove function.

You know, it's really helpful for trying to understand,

you know, what are these functions that are getting passed around.

That are, that are holding to these variables.

In stack traces it's really helpful as well, but in this type of scenario it,

it helps us get some clarity on what that function is.

So we showed how

you can name that function now how would we how would we clear up this memory leak.

Well the easiest way probably is that we we could set dollar l to null

and so, why, why does that work?

Why are we doing that?

Well, we're always gonna to have a reference to dollar l, but dollar l

doesn't always have to have a reference to that element that's not getting removed.

If I set it to null, you know, this, this function still has reference to l,

but dollar l is just not the element.

Of course, we probably wanna check that dollar l exists before calling remove if

you clicked it multiple times.

So that's an easy way to clear up that leak.

But I want to talk about something now, the delete keyword.

So, we set it to null but I'm sure you've heard there's a delete keyword.

We've used it in JavaScript.

Should we have just deleted the variable, wouldn't that kind of nuke it so

dollar l didn't exist anymore?

Well the delete keyword is not intended to be used on variables.

So if I create a message for

variable I deleted and then I log it out it's still there.

Delete keyword doesn't work on variables.

It's not supposed to.

Delete keyword can be used against properties.

So you know I can do delete data.name.

And then I can do typeof data.name is undefined.

So that's where it can be used, but you really wanna be careful with it cuz it,

it can cause some major issues with optimization.

I would like to show that really quick here cuz I think that it,

I found this really interesting.

Let me flip over here.

So let's say I have these my thing objects with a name and an ID.

And let's say I have a function called clearName.

And the thing about this clearName function,

there's two different implementation of it.

One I'm going to set it to null, and one I'm going to delete it.

Delete the property.

And I thought this was fairly interesting.

So when I, when I do this I'm gonna allocate a a thousand of those and

then and I'm gonna clear the name.

And take a heap snapshot.

So actually summary is good.

I'm gonna look at my thing here.

I can see 1,000 of them.

I can see that shell size, that contain size if I dig in.

I can see 20 bytes, 20 bytes, you know.

Not very much memory it's taking up, you know, if I hover over one,

I can see that it's id1.

I can see the name is null.

Now, if I do the delete.

So if I actually delete that name property when I'm creating these objects and

now if I do a snapshot, thought this was fascinating.

Look at the size now.

12,000 channel size cuz I really deleted that property now.

Look at the retain size, 424,000 bytes.

Look at each one here.

12 and 424 instead of 20 and 20.

So by deleting properties off of that object you've really messed up some of,

of V8's optimizations and could be the same in other browser as well.

Now just a little bit about delete and how it can be a little bit dangerous for

as far as optimization goes.

But the delete keyword, I don't wanna say,

don't ever use it cuz there are some interesting uses for delete.

Generally you could use delete when you want to remove a property such that you

can't iterate through the properties of an object and

find it or use hasOwnProperty to find it.

Or, you know, when you want to differentiate between a property

existing versus having a value of undefined.

So if I have an index object here with someId as undefined.

I have Index 2 as an empty object.

If I just look at the type of each of them it tells me undefined and

that's not very helpful.

I can't tell the difference between whether someId was even in there.

Now I could do someId in index, you know, that would tell me the exact property can

I iterate if I was iterating through would I find it?

That's true.

You know, I might wanna do has own property instead because.

That would get just things on an object, not on its prototype.

For example, toString I could find, in, you know, if I was doing that on index,

I would find toString, so so my, my point is that if you do want to use delete it

still, it still is okay to use it in situations like this.

Perhaps you have a long running index where things are coming and

going, keys are coming and going and you really don't want it to

end up with thousands of keys where most of them are undefined and

when you iterate through them you'd have to throw out the undefined one.

So delete in that case is still a very valid,

that's the very valid way to use it.

Okay, a little bit about references and closures.

So I made a change to the code we were looking at before and here's the change.

I am not using dollar L down here anymore.

I'm not using dollar L in our remove function.

Remember that was our problem.

It was hanging on to dollar L,

well if I don't use it then we should be good, right?

Well it can be browser dependent, but in some cases.

But in Chrome for sure, and in IE all of the functions that are created within this

scope seem to have some level of sharing of the variables that they're closed over.

So even though I'm not using dollar L, it's still,

it's still is, considered a reference of this function.

And interestingly in chrome, if I were to comment this out, comment out the click or

even just comment out that dollar L dot text,

now even though I created that variable, It's not actually included so

in my opinion I want to kind of rely on these tricks.

I want to make sure that you're safe in all browsers.

So how can we do that?

Well in this case one thing we could do is move our block out of the IIFE.

You know if I move it down here it has no chance to access [UNKNOWN],

no chance to use it.

Of course we could just not use a variable there you

know if we don't need to cash in.

Maybe we could do it that way.

One of the things that I do most often is try to create functions you know,

maybe it's not just hanging out here globally but

create a function to handle what I want to do and then pass that function directly.

So, try to avoid anonymous functions when I can, and,

only include the things, you know, the things that I need.

So, this would be another way to not include dollar L in that function.

And finally you know,

once we call that clear we don't really need that event handler anymore.

So what we could do is we could remove that event handler.

So in, in the code down here we could do an off or

something like that but in this case I'm choosing to use one.

That's not a typo, I didn't mean to use on.

One is a convenient way to do a one time event handler, you, it'll call it

when you click on it and then it'll automatically remove it for you.

So, I found that to be kind of useful for sort of that one time situation.

Now this one has, has got me before several times.

I don't even want to admit it, how many times this has actually got me.

Be very careful if you're investigating memory leaks.

Be careful about what you're doing in the consult.

If you're logging out elements or objects, and they're sitting there on the console,

they're not getting removed, even if they could be.

So, I've had cases where I'm investigating memory leaks and I am

trying to do some logging to understand when things are getting created,

when things are getting disposed.

What element is that?

Where is that?

You know, maybe I logged out the parent to see where this thing is getting rendered.

If it's in that console it actually won't get released and

you can start setting everything you think of to null and it still won't get removed.

So just as part of an investigation be careful with that console.

In the use of eval, eval, you know,

I really don't think there's a lot of great uses this for eval at this point.

If you have a bunch of [INAUDIBLE] string you gonna wanna do [INAUDIBLE] You know,

if you want to dynamically access a property you should be using,

you know, the syntax where accessing the property [INAUDIBLE] so,

eval is not you know, something you should, if you are using eval,

you may wanna rethink while you're, while you're doing that.

But the interesting thing here is that if I eval, even in this case,

I'm just evaling an empty string that does nothing.

But if, if the optimizer sees eval,

it say I may need all the variables that I could possibly access here.

So Dollar L actually gets included, in this closure, because, it doesn't know,

even though this ecstatic text, mabye it should know but,

yeah, eval is [UNKNOWN] definitely a good way to go.

Yeah, I could see, you know, ligament use of eval mabey some type of data binding or

something you have in an element.

[COUGH] You know,

where you actually gotta take some text and turn it into some job script object,

or, code, but, you definitely would want to isolate that as much as possible.

Okay, scenario number four, this is gonna be quick.

Timers and parent child links.

So that first sample we saw in the timeline,

where we saw its memory growing and growing.

This comes from a real sample from a code review.

Two things to remember,

if you starting timers or intervals, the code here is not too important I think.

This is a little more interesting.

If you're starting the timer on interval, and

then it's possible that you're going to be removed before that timer comes up,

you know, be sure to keep track of the idea of the timer or

the interval and then call clear time out or clear interval.

So if you're creating some reusable thing and you're adding some timer, maybe you're

watching resize or you're, you're doing the eject request,make sure you

clear out those timers coz, coz they're a major source of memory leaks as well.

And then, you know, this is nothing special.

Remember we saw that previous, previous, previous, previous.

You know, be careful with parent child links and

cascading links, to things like that, you know, that burned us.

Burned the project in this case,

but it, just, just make sure you careful about how things are linking like that.

Scenario number five, this is the last of the scenarios.

So now Doug yesterday talked a lot about messaging and subscriptions.

One thing to note.

And, and this is kind of similar to events that we've talked about already today but,

in the observer pattern or

in pub/sub, which we'll, which I'll bring up as well here.

When I'm doing something like item type subscribe,

passing in myHandler and my context.

What happens is that item type some other

variable somewhere else has a reference back to me.

So I'm creating my object yay and then, I'm subscribing to this item type thing.

It has a reference back to me.

If I don't type lives longer than I do.

I can't go away as well, coz it links to me.

Same with pub/sub.

I mean, amplify.subscribe, amplify, a library that, that appendTo has

written to, that, that can do some pub/sub among, amongst other things.

And here I have a topic and again, passing my this and someHandler.

Amplify is definitely going to live, a lot longer than,

than my object that I'm creating.

So in that case if I don't unsubscribe,

I can never be cleaned up until that subscription is removed.

So let's say I had a basic view and somewh, the requirement

I had was hey when there's a session time out, I need to set active to false, so

I can subscribe to some session timeout topic and then set it to false.

That's great, that solves our problem, we're decoupled, you know we have that

subscription and but again amplify's going to

hold onto that reference to the view that I create forever unless I unsubscribe.

So it's something to be mindful about.

A few lessons learned from some of the situations I've seen.

Be very careful with integrating third party code.

Talked about it at lunch today but you know the way you're using it may

not match the author's intention and it certainly is fine to post issues and

try to go back and forth and try to improve that library as well.

But just be mindful that when you're pulling in dependencies,

don't just look at what it can do for you.

Make sure it fits into the scenario you want to use it and

make sure you can clean it up.

Be mindful of globals I'm not gonna see any more out there

I think everyone's pretty aware of, of how that would work.

earlier, when you're creating reusable pieces of code,

whether you call it modules, components, bindings,

directives, whatever you're creating, you know, think about life cycle, don't just

think about I need to put this date picker on the page, I'm gonna create a directive.

Think about what it means to remove it from the page.

Do I need to call destroy, what exactly do I need to do?

If I've created a timer or an interval,.

If I added a Window event, make sure I can remove it.

If I'm doing things like adding Window events, don't, you know,

use name space [INAUDIBLE] jQuery, or

keep track of your handlers, you can directly remove that handler.

It's all things that, that you should think about.

Just, just like the functionality you're creating.

Think about it as far as how it's gonna get destroyed, as well.

Login and instrumation, instrumentation are really useful.

Sometimes you may want to stringify your objects, so

it's not actually holding on to the actual object.

Just a string representation of it.

Or potentially build new objects with just the little pieces that you do want to log.

You don't really want your logging to, to be the thing that causes the memory leak.

Okay, quickly here.

Clean up time.

So I just wanted to point out a few libraries out there.

I'm just gonna ask the chat right now to tell me, as far as the,

the projects, does anybody use things like Knockout, Angular, Ember, Backbone React.

Is anybody using any of those libraries today in their apps?

[SOUND] I'm gonna,

I'm just gonna quickly go through some of the way that you can do disposal in these.

So knockouts are what I'm most familiar with.

If you're in custom bindings and, and really my intention here is that you

can come back and review these slides so I'm just gonna cover them really briefly.

If you're inside a custom binding you can add a dispose callback to the elements.

When that element gets removed you can run some cleanup code.

If you happen to create a computed observable in a custom binding,

you can add an option to say, remove this for me automatically.

Dispose of this automatically when you, when the element's removed.

If you're creating computed observables or

subscriptions you can manually dispose of them, if you need to.

And generally, when you wanna do that is when you're subscribing to

something that lives outside of your object.

Let's say, on my view model, I happen to subscribe to something on the app.

I may need to run dispose because again app has that link back to me,

and I can't be disposed, I can't be cleaned up until that link is broken.

Angular has some destroy events.

So, like on, on, on any scope, you can subscribe to that destroy and

do things like cancel timers.

Elements that actually fire a destroy event,

as well so another scope of the element if you're in a directive,

you could potentially be cleaning up something like a date picker.

Ember. I know Ember the least here.

I've done just a minor bit of work with it.

There are some component life cycle hooks will clear render we'll destroy all

mention of the ones to look for.

One is called whenever it gets re-rendered.

One is called when it's actually going to be destroyed,

so those are two hooks that you can use to do clean up.

In backbone, a while back it would be more common to

see things like this.model.on change an color code.

Again this is exactly like the subscriptions when you do this.

Desktop model has a reference back to you.

And so what you need to do is make sure that you're calling off.

But in, in more recent versions of Backbone, .9.9, was,

0.9.9 was when it was added, there's a new API called listenTo.

That kind of flips it around.

So instead of seeing this step model about all of it, you can say this.listen to,

pass in the model, the change and, and the handle you want to run.

Under the covers, it still does that subscription that was previously being

done, but it's able to keep track of it.

So it removes it automatically for you.

And, if you need to you can use this stoplistening API to force it as well.

So in Backbone be careful about the subscriptions you're making and

listen to will help some of that automatically.

In the events that you add in a Backbone to use those will automatically be

removed as well.

React is picking up a lot of steam right now.

I expect to see a lot more out of react and future times here.

Component will unmount their life cycle method, life cycle event that gets called.

Here's where you can do cleanup for React component.

So as far as the future of memory leaks in modern web development, I think,

I think there's a bright future.

Browsers are always improving and frameworks, the libraries are maturing and

a bit reason for that is because the tools, tools keep improving.

And it's just a cir, it's a circular thing as the tools improve you know, you're able

to eliminate more and more leaks from these different libraries and frameworks.

And also people are more aware of the type of things I talked about today.

People are more aware of closures, people are more aware of removing event handlers,

that type of thing.

And new language features in es six.

There's something called weak map it's basically a hash where the keys do not

have to be strings.

You can actually use a dom element or, or an object as the key but they don't

hold onto that memory so they, they won't prevent something from being cleaned up.

And that's it. I'd be happy to stay around and chat.

And I'll post a link to this presentation in there but

I hope that you can start taking a look at your applications and, you know,

fingers crossed that you don't have thousands of detached arm elements.

But yeah, definitely give it a shot.

I'd love to answer some more questions if you have them.

And thanks for having me at Modern Web Conference.

>> I think a bunch of us were saying that this was like really a 600 level talk.

So, this was amazing.

I think a lot of minds were blown.

I had one question that I, I was able to, able to grab, I wanted to ask.

Somebody was, I forgot who, I apologize, I didn't capture that.

Was wondering if is there some memory leak difference be,

using single quote versus double quote for strings.

>> No, no, not at all.

>> If any of you have >> Not to my knowledge anyways.

[LAUGH] >> I didn't think so either.

I didn't see any other questions, or I didn't capture them, I'm,

I might have missed them.

if, Laura S has a question.

So you would not recommend dollar sign dot remove for huge element blocks?

>> Well really the issue is, is, is that.

So I had something inside that block that had a,

that, that was held on to by something outside of it.

So what it was, it was a window event.

So when I added that window event,

the window, or actually add a link back to something inside that block.

So it's okay to remove it, but if, if everything is self-contained,

if all the event handlers are inside that block, it'll get cleaned up automatically.

But it's just the fact that we add something outside that we

were subscribed to.

It could be Amplify, it could be a Window event,

it could be something outside that's pointing back to us.

That's a lot of the cases where, that problem comes in.

The one other thing I just would say is that.

You know, if some of those, those stack traces some of the digging into that

looks kind of complicated, I mean it, it is a bit hard to interpret,

I mean I'm not saying I'm an expert in interpreting it.

I think the, the best thing I can say is it takes some trial and

error and it, you just kind of have to get into the right area,

to say oh, okay, it's a scroll event let me start looking into that.

You don't have to really just dig into and

say there's the leak I'm gonna just go fix it right now.

It rally just gives you kind of the ballpark of what I should start looking at

In some case it would take some trial and error.

I don't think any of us wants to just start setting everything to null.

You know I don't want to add extra code setting every variable to null

all the time so it, it takes a little trial and

error but you know just it gets you in the right ballpark