JavaScript Garbage Collection is This SLOW????

I did a fun experiment to expose the cost of GC

### Links

### Twitch
Everything is built live on twitch
Twitch :
Spotify DevHour:
### Editor
All my videos are edited by Flip. Give him a follow! He is also open to do more editing, so slide deeeeeeeeep into his dms.

Join this channel to get access to perks:

### Links
VimRC & i3:
Keyboard 15% off USE CODE PRIME360

#vim #programming #softwareengineering


  1. My favorite type of videos from you! I use JS all the time and see the spread pattern constantly, never thought to consider the GC impact under the hood but makes total sense!

  2. I don't think people are going to listen to the last part of this video. You only need to be concerned about this if you profile your application and you're seeing that you're having an issue. In the real world you likely won't be creating millions of objects and then deleting them and if you are then there's likely a much bigger problem in your codebase than object spreading. When I code, I code for developer productivity. If there is an issue with performance that's when you pull out the profiler and see what you can do to increase performance. "Premature optimization is the root of all evil" – Donald Knuth

  3. This is great thanks. I usually don't worry too much about it since if I'm using JavaScript it's not in a performance = money scenario

  4. I’ve heard that reference counting is a good strategy for UI’s. Would this mean that front end apps could get better performance with Rust and Wasm using ref counting (as wasm catches up with V8)?

  5. the deepest video about JS I've ever watched lol, now I know that I have a long road before me to become like you @ThePrimegen

  6. I love this!
    This is the data based advanced stuff that no one else on YouTube really does. With realworld fang experience to back it too!

  7. The idea of an object pool in a library like fastly sounds like (if I understand correctly) it would be incredibly easy to misuse, because the user needs to be very careful when to release the request object. On the one hand, if you release it too early/hold onto the object for too long and (for example) use it across an await point, the JS engine may well execute another request and it could reuse the released object (and effectively write request data of the new request to the object which is still in use by the other request). Then once it goes back to executing the old request, it has all the request data from the new request. On the other hand if you forget to release the object, it "leaks".This sounds almost like manual memory management but in JS

  8. I wrote a streaming regex engine and it hammers the GC pretty hard because it needs to create an object for each state it passes through, and on any real text and expression it passes through a lot. I studied its perf because I thought I'd have to pool the state objects, but instead profiling showed that I was only spending ~20% of my time doing GCs. That's because v8's generational garbage collector is optimized for the collection of objects that are small, short-lived, and have a common structure/shape. Engineers should not shy away from using those kinds of objects!

  9. I really enjoyed this video and yes I would like to see more content where you do a code review just like this. Youtube is filled with junior developer content. It is hard as an intermediate to find content that improves your skill set/skill level. I think with your knowledge base your technical review of code is extremely beneficial.

  10. What a shit show. The fix is the ugliest thing I’ve ever seen. If the garbage collector had any sense of professional pride it would gobble the whole language and set itself on fire.

  11. quite good amount of code, it did really well, nice explanations
    not… blazingly fast, BUT it is HOW to become blazingly fast!

Leave a Reply

© 2023 53GB