WHY IS THE HEAP SO SLOW?

In this video we take a look at the heap. A memory region that is feared, but it exists because is necessary...

Contact email:

Suggest topics for future videos by:

[ThePrimeTimeagen]

This was so good i would just like to say. And my great great great grandson, William, is very primed and ready to tell you about u8 and their downfall

[chicoern]

Absolutely great video. You managed to cover almost everything and keep it simple. There's only one huge problem. I'm 257 years old and that invalidates everything.

[TheSast]

I think they were just mad that vampires ages would be excluded by that u8

[JinTheAceStar]

according to that commentor we cannot write any program because the parameters of our living world may change any second...

[isuckatthisgame]

This guy is one of the better discoveries I've made on YouTube in quite some time. This is helping me pass my Operating Systems exam. Btw, books referenced couple of times in your videos are the same ones I'm currently learning from. Great minds think alike. 👍

[MrSonny]

That "as an AI model" jab with the voice was hilarious. This was a great refresher since I could hardly remember anything from my own operating systems unit.

[AntonioZL]

I'm a self taught developer, so your videos fill many gaps in my knowledge of architecture. Keep doing them! You're a gem on youtube!

[yipyipisyip]

Excellent video. By far the most educated explanation to stack vs heap without digging unnecessarily deep to lose the point.
I love the part you reiterate what “heap is slow” actually means “heap allocation is slow”.
Would love to see a follow up video on how to access heap fast by leveraging cache-line alignment, packed data structure etc.
from day to day i got worried about accessing the heap memory in hot path, even it is a pre-allcoated once vector to be reused for each loop - i can’t reason about for every loop whether or not pre-allocating a dynamic size vector on the heap (and perform a clear upon each loop) or use a large enough fix sized array so it’s on the stack always (although potentially waste of memory coz you can only expect the worst case size of an array at compile time)
Looking forward to the next video.
Greatly appreciated

[Darkev]

F I N A L L Y! Someone that doesn't go high-level but rather goes in depth to provide low-level content that is presented very elegantly!!! SUBBED

[TheDragon]

Such an informative video, the visualization and commentary deserves a lot of credit. I enjoyed it thoroughly!

[NeetCodeIO]

My new favorite YT channel. So amazing, cant wait to see more

[MohitDharmadhikari]

Excellent explanation of complex concepts! I wish if you can cover Booting, BIOS and UEFI in detail along with MBR and GPT partition internals. Namespaces, CGroups and File systems deep dive

[minoubrc]

Heap and stack management are two of the most fundamental topics in programming languages, and understanding them can spare a lot of headaches so you can secure and debug your program easily. Thank you for your videos. Keep it up.

[mattshnoop]

This video is EXCELLENT! Like you said at the start, there's some simplifications—but it's totally accurate and very comprehensive.

I'm one of those "more experienced people" you mentioned at the start (at the end of an extended 6-year undergrad in compsci), and I'm impressed by how much info has been crammed in here. I'm about to start a master's degree with a focus on pedagogy (the study of teaching), so you can imagine I spend a lot of time explaining these topics to my juniors. I think you've found an excellent level to simplify things to for someone who may be new to this sort of thing. Good examples always help, and you transition to them well and the "story" of the video flows well.

Great work on this video. I'm going to go and watch the first video on the stack, too. Even if I've thought about this stuff a ton over the years, this was a great refresher on a few of the concepts I've gotten rusty on (pun not intended) or even completely forgotten about. Looking forward to the next video!! 😄

[mike]

Great video! Good explanations at a nice intermediate level! I can see a couple of things to add for a bit more depth. First, the performance problem with allocating memory on the heap is a good example of where it's more about the variance (or unpredictability) than the typical case. For most reasonable heap implementations and kernel page allocators, allocations will be really fast, but a small number of times, it's going to be really slow, and that can have significant impact on "quality of service". Second, in that vein too, I would say the overhead of requesting memory from the OS / kernel isn't really the context switch. That's pretty negligible compared to page allocation. What's really bad is the kernel lock. The point is that the kernel has to deal with multiple processes requesting memory at the same time, and so, it has to have a global lock to synchronize those allocations between processes. Clever things can be done to avoid hitting that lock too much, but it still has to be there and you will inevitably hit it. This is one of the few places where multiple processes on a system directly interfere with one another (beyond just generally sharing limited CPU/Mem resources). And kernel locks can be a big deal, I've seen wait times in the order of a few seconds when hitting a kernel lock, which can be a major disruption in the middle of an operation you expect will only take a few milliseconds.

[blackbriarmead]

After I wrote a compiler, I realized that a lot of the power comes from the fact that you can use relative references from the knowledge you have about the stack at compile time, which makes it so powerful. There is no lookup, it just knows the address of the variable you are trying to access. This was after optimizations, at the layer of code generation.

[sprytnychomik]

There's one more thing that can make stack faster. Instructions may use immediate addressing relative to the stack pointer. Accessing data on the heap requires loading its address to a register first (not on all architectures), which not only is an extra instruction but additionally makes that register unavailable for anything else.

[ejdueit]

I feel extremely lucky to have found this video. Very informative. Please continue on making more of these ones.

[joeedh]

The explanation at the very end is much better than the entire video, except for GC which does not protect against leaks anywhere near as much as people like to believe; there is such a thing as reference leaks.

[thunder____]

The comment put on blast in this video makes me think of something John Carmack said in his appearance on Lex Fridman's podcast; I'm definitely paraphrasing, but Carmack said something about how it can be useful to include limitations in your software that will notify you when things have changed greater than you ever thought they would. He was speaking in reference to limit-removing ports of the Doom engine, but I think it's pertinent here too. It's okay to write software that addresses your current needs and your current use case using the technology currently available, and sometimes that will force you back to the drawing board to some extent in the event that something related to your needs, use case, or technology changes, but that's not necessarily a bad thing even if it causes more work, because if something has changed that much, it's quite likely that other things have also changed such that other parts of your software need to be revised or at least reevaluated.

So basically, what I'm saying is that the event of maximum human lifespan more than doubling from its current state would probably be part of much broader and more sweeping changes to the world that would call for a more holistic revision of your software. But because there does not seem to be any realistic probability in any remotely foreseeable future of a human being living to age 256, it is perfectly reasonable and sensible to represent human age with a u8.