For me, this was one of the most useful episodes so far, on a tool I have mostly avoided thus far. Also it felt like reading a suspense novel after every “success.” Thanks for the great walkthrough!
I feel like we're passively/partly enabling Apple to keep on slowing down the web by supporting its browser. Sometimes, I just wanna add a banner telling people to use a proper browser. In my last job I had a native datepicker, and for safari, i had a input/text with clickable question mark next to it that alerted "your browser does not support date pickers, please enter date manually dd-mm-yyyy"
This seems like an uninformed answer. All three major browsers do a great job in certain areas and less than great in others. None of the development teams *want* any of these bugs to exist, they're bugs. Safari is usually not too slow to fix things like this anyways.
I work on a big typescript application, and memory leaks haunt us from all places, kind of 70% us, 20% libraries, 10% browsers fault. Sometimes I think it would be easier if we write everything in C.
Am I the only one who likes video before watching it fully? My mind after watching this video: Lets run and analyze memory on every site that we have created. :)
Wow, guys! Keep it up with this format, I loved it. It has been one of the episodes I've learned the most and I can actually use this to solve my everyday problems.
Jake and Surma are the Messi and Ronaldo of the software dev world 😄 Constantly amazed by their smarts and I’m thrilled that they share it with us mere mortals!
Haven't watched fully yet. But last mem leak issue i had was related to Audio context, the mem used there cannot be seen in devtools and must use taskmanager. That day i learnd that mp3 loaded into an js context takes 10x the filesize in mem.
Decoded audio will always take up more space than compressed audio (like decoded images in this episode), but please file a bug about the lack of attribution in devtools!
It's great learning things. Awesome explanation. If video gets longer.please keep it following video as part - 2 so on. It's helps alot in understanding the things under the hood.
I'm liking the new "studio", although those raining artifacts are really annoying. I think it would be useful to have a similar episode to this but talking about the DOM itself. How can we minimise the memory usage when we have a very large DOM? Also, it seems like it would be useful if those memory tools had a button that can remove from the snapshot anything that is _only_ referenced by the console
--disk-cache-dir lets you change the location of the cache, and you could create a ramdisk for this if you wanted. I don't know what you're trying to gain from that, and I don't recommend it, but that's all I know.
The big question is: do we have to remove listeners from elements that are going to be removed from DOM or are they automatially destroyed if the element is garbage collected after removal?
DOM nodes always cleanup after themselves, meaning that listeners are removed/freed. However, working in a world of components, it is easy to forget to handle global listeners properly. In React it is generally done in useEffect callback function.
Event emitters are pretty much literally just an array of listeners, so it's less "cleaning up after themselves" and more the GC just tosses the lot out at the same time. In practice the GC is just making things easier: you still have the basic problem of having to ensure that you have a protocol for ensuring things are cleaned up after they are no longer used (at least you don't have the problem of making sure they aren't cleaned up before they are used!)
![Understanding and Debugging Memory Leaks in Your Node.js Applications [I]](http://i.ytimg.com/vi/hliOMEQRqf8/mqdefault.jpg)
![АЛАУДИНОВ у Скабеевой: эти их ВСУ нас НЕ ДОГОНЯТ 😁 [Пародия]](http://i.ytimg.com/vi/an0anqU4WGQ/mqdefault.jpg)
I've added a link to the leaky version of Squoosh in the description, in case you want to follow along
For me, this was one of the most useful episodes so far, on a tool I have mostly avoided thus far. Also it felt like reading a suspense novel after every “success.” Thanks for the great walkthrough!
These episodes could be an hour long and I wouldn't mind. Great content as always!
I feel like we're passively/partly enabling Apple to keep on slowing down the web by supporting its browser.
Sometimes, I just wanna add a banner telling people to use a proper browser.
In my last job I had a native datepicker, and for safari, i had a input/text with clickable question mark next to it that alerted "your browser does not support date pickers, please enter date manually dd-mm-yyyy"
This seems like an uninformed answer. All three major browsers do a great job in certain areas and less than great in others. None of the development teams *want* any of these bugs to exist, they're bugs. Safari is usually not too slow to fix things like this anyways.
Really informative and entertaining as always, so glad you're back!
I work on a big typescript application, and memory leaks haunt us from all places, kind of 70% us, 20% libraries, 10% browsers fault. Sometimes I think it would be easier if we write everything in C.
Am I the only one who likes video before watching it fully?
My mind after watching this video: Lets run and analyze memory on every site that we have created. :)
Everyone should do this, I reckon
@@jakearchibald Yup Cant agree more. I would spread the word for you for free. But there is hardly anyone who listens to me :)
Exactly the procrastination I needed while learning for my exams, really glad to see you’re back!
Wow, guys! Keep it up with this format, I loved it. It has been one of the episodes I've learned the most and I can actually use this to solve my everyday problems.
Jake and Surma are the Messi and Ronaldo of the software dev world 😄 Constantly amazed by their smarts and I’m thrilled that they share it with us mere mortals!
They're more like Chet and Romain from Android staff!
Yay! Thank you! Google Chrome Developers series is my favorite! 😄
Haven't watched fully yet.
But last mem leak issue i had was related to Audio context, the mem used there cannot be seen in devtools and must use taskmanager.
That day i learnd that mp3 loaded into an js context takes 10x the filesize in mem.
Decoded audio will always take up more space than compressed audio (like decoded images in this episode), but please file a bug about the lack of attribution in devtools!
Epic, I never know how to tame the memory tab. Could you maybe do other features of the inspector in following episodes?
That was worth the wait. Thank you all, it was great 👌
Such a good episode!
that safari memory usage,, 1.2 GB by the end.. that's just surprising. thank you for the video, super helpful.
its funny that even a google channel makes fun of Chrome`s memory usage problem xD
It's not a problem, it's a feature. Since everything you do should be on the web anyway, the browser might just as well use all your memory :)
It's great learning things. Awesome explanation. If video gets longer.please keep it following video as part - 2 so on. It's helps alot in understanding the things under the hood.
guys you are the best. this content is pure gold
I like how they gently pulled the leg of Safari and Firefox :P
I'm liking the new "studio", although those raining artifacts are really annoying.
I think it would be useful to have a similar episode to this but talking about the DOM itself. How can we minimise the memory usage when we have a very large DOM?
Also, it seems like it would be useful if those memory tools had a button that can remove from the snapshot anything that is _only_ referenced by the console
the studio seems professional but the audio is somehow bad.
Yeah, we had some sound issues in this series, sorry about that.
Wow this feels great, learn many things here
Insightful and lovely convsersation! thanks.
Both were event listeners, that's great
Awesome information guys
Thanks for this episode, it was very informative.
4:18 - my favorite scene 🤯😂😂😂
This is really helpful video! Thanks a lot!
Great video!
Great episode !
you guys are the best
nice content, well presented. Thanks
very useful and interesting, memory leaks debugging is always dev-time leaks :S
What a great explanation 👍
Where is upvote 100 times button
Would be awesome if we could do something similar in node.
The trash can with an X in the top right is a CollectGarbage button in Safari
hah, I think I assumed that was "delete". Same UI problem as Chrome.
Another insightful conversation / presentation. Thank you! Is there a way to detect these leaks in production via RUM?
Wow great. nice point of logging in console is breaking memory usage. keep going
So you use a memory leak profiler to find a memory leak in your app only to find memory leak in the profiler itself. 😂
haha not just the profiler, it was a leak in Safari in general!
Thank you very much. it was so much informative
Really interesting 👍
Oh Safari
Fantastic
Nice subject!
Is it possible to use ram for cache not my ssd
--disk-cache-dir lets you change the location of the cache, and you could create a ramdisk for this if you wanted. I don't know what you're trying to gain from that, and I don't recommend it, but that's all I know.
@@jakearchibald thank uou so much sir ❤
15:55 😂
excellent ! and quite readable even on smartphone ;-)
safari is the new ie
I didn't get what is unfoldable thing at 10:49 . Can some explain.
The bit where is displayed? That's the JS console
The big question is: do we have to remove listeners from elements that are going to be removed from DOM or are they automatially destroyed if the element is garbage collected after removal?
DOM nodes always cleanup after themselves, meaning that listeners are removed/freed.
However, working in a world of components, it is easy to forget to handle global listeners properly.
In React it is generally done in useEffect callback function.
Event emitters are pretty much literally just an array of listeners, so it's less "cleaning up after themselves" and more the GC just tosses the lot out at the same time.
In practice the GC is just making things easier: you still have the basic problem of having to ensure that you have a protocol for ensuring things are cleaned up after they are no longer used (at least you don't have the problem of making sure they aren't cleaned up before they are used!)
No more bedrooms!
Hey, there was only ever one bedroom. Unless you think I sleep in my study? Which… I guess is believable.
You just wait. I’ll demand that there’s a bed on our set!
Interesting...
Is window.matchMedia any more performant than window.onResize? Or it depends?
Roughly the same in terms of performance I imagine. I went for matchMedia because it followed what we were doing in CSS
May I ask what set-up you are using to control your slides with a Joy-Con? 👀
It's just bluetooth, so it connects as a gamepad. Then we're using the gamepad API in the browser to pick up button presses.
@@jakearchibald Oh, I didn't realize Joy-Cons map like regular gamepads-thanks!
Am I the only one seeing the artifacts in the video?
What kind of artifacts? What quality are you watching at?
Hello,, salam kenal dari aceh
First!
Great video!