I Fixed Your Out of Memory Errors Forever
ฝัง
- เผยแพร่เมื่อ 15 ม.ค. 2025
- Join this channel to get access to perks:
/ @thecodinggopher
☕ Buy Me a Coffee: ko-fi.com/theco...
💌 Inquiries: thecodinggopher@gmail.com
👨💻 Thank you for watching, and happy coding!
You are one of the people who are helping us to advance from beginner to intermediate (my internal measurements could be wrong) ❤😊
❤!
thanks gopher, u really did fix all my out of memory errors forever
How are you able to produce videos with so much speed?
I dedicate a lot of my time every day to recording and editing videos. It comes down to staying disciplined and prioritizing video-making over other activities
Here's a comment to boost your mood and lift you up! This was fun and easy to watch, i honestly enjoy all of your golang related topics/videos, mainly due to my interest in the language itself, but damn you make watching videos about it fun and educational. Hands down no other channel delivers the same quality of content/production with a matching quantity of knowledge per video. Simply said, i love your content ❤️
Best wishes for you and your channel
Thank you for dropping by again. As always, love to see your icon pop up in the comment section. ❤❤
Along that same vein, a lot more Go videos queued up
You know, all this new "coders" could go get proper basic computing science education.
Can you change the allocator that Go uses by default? I've found that the best way to avoid memory fragmentation for long running applications is to use arena allocators, and if you can swap that out in Go that'd be one fewer problem.
Hey! Thanks for dropping by; sadly Go doesn't allow swapping out the default allocator. It actually uses a custom memory allocator optimized for goroutines / garbage collection. For finer control, you can use `sync.Pool` / manage memory manually, but arena-style allocation isn't natively supported :(
@@TheCodingGopher So you'd have to turn off GC and manually do arena allocation? I'll have to add that to my list then.
@@anon_y_mousse Go doesn't provide a way to turn off GC, but you can reduce its impact using GOGC (e.g. try: GOGC=off or GOGC=1000). GOGC=off doesn't turn turn off GC, BUT it does disable automatic garbage collection triggered by heap growth. GC can still trigger because of things like finalizers or explicit calls to runtime.GC(). For arena-like allocation, you'd need to manage memory yourself; sync.Pool can help with object reuse, though it still interacts with the GC.
@@TheCodingGopher What about the @nogc attribute when you use that on functions? Does that do the same thing or does it have different semantics?
Considering that this video is merely for developers to modify their code, and solely for Go, its title is deceptive. I've never experienced OOMs from my own code - solely others. I consequently expected a video about a tool that prevents hangs during OOM scenarios as a user.
True, i primarily code in python and the only times i get an out-of-memory error is when i do some black magic with machine learning libraries.
I thought this video was going to recommend a universal defragmentation-like tool for RAM.
Fragmentation doesn't actually exist in this form, since all allocations are in size pools in power of two sizes, so when an allocation is reclaimed, another allocation of the same size lot guaranteed fits in there, this chunk will never be fragmented further. But you have an issue when typical allocation size changes as the program lives on, for example if the first hour most of the allocations are 1k in lot size, the next hour 2k etc, then you have underutilised semi abandoned pools remaining hoarding the memory.
Read dlmalloc, it's the foundation of all modern allocators.
How deceptive! This is only about Go. 👎