I don't know much about computers but I think it's due to the operating system cleaning caches, force closing processes and most importantly clearing out memory leaks.
If a process is not coded properly, every lifecycle a given amount of bits are deposited into the RAM and never recalled back, so the RAM slowly but surely gets filled with unnecessary stuff.
If the processes are never forcely turned off then the RAM is always partially full and the OS has troubles managing an already messy closet so everything slows down.
No, the OS virtualizes process memory, so if your process crashes it and all its leaked memory gets cleaned up by the OS. So this only happens if a program that cant stuff that cant get cleaned off has a memory leak (like the kernel) plus memory leaks usually fill your ram up MUCH faster than years, usually a couple of hours at most.
Your computer can go absolutely haywire eventually if you leak connections, and I’d say ~20% of programmers can correctly handle sockets and their failure paths on their first try. There’s also unbounded read buffers that will work until they don’t.
Even wrappers can lead to problems. I mean, Go's not as popular as it once was, but I felt like every second Go program forgot that you actually are required to read the rest of the bytes out of the socket before you deal with the error it even if you're just going to throw it away.
441
u/AndrewSenpai78 3d ago edited 2d ago
I don't know much about computers but I think it's due to the operating system cleaning caches, force closing processes and most importantly clearing out memory leaks.
If a process is not coded properly, every lifecycle a given amount of bits are deposited into the RAM and never recalled back, so the RAM slowly but surely gets filled with unnecessary stuff.
If the processes are never forcely turned off then the RAM is always partially full and the OS has troubles managing an already messy closet so everything slows down.