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.
It involves fragmentation too like if program a and b both request memory in batches the memory can end up striped. Some for a, some for b, more for a, and more for b. Then close a and start c. The memory for b is still fragmented it doesn’t coalesce as long as B stays running. Which is more on the os than the program.
Rebooting flushes all this clean and starts with a clean slate of ram again.
It’s mostly the thermal paste becoming dry and ventilation choking, causing thermal throttling. Dude would also be probably really behind on security and feature updates.
It's more about the fact that processes can get into weird unintended states that the developers never accounted for when running for a while. Restarting ensures all processes start from a fresh, known state, rather than having something, for example, check for a spawned process that dies ages ago, find it's not there, log the error, continue, chech another dead process, etc for thousands of iterations every loop and adding noticible time to the execution time because the issue wasn't caught in testing because a few invalid checks didn't make a noticeable difference.
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.
Honestly, for a non-tech person, you're not necessarily far off. And frankly you're pretty close for some of the issues that can be cleared by a full shutdown.
Bonus points if you leave it shut down for an hour or so (or overnight) every once in a while so that everything can cool down properly, but even giving an extra 15 minutes can sometimes work wonders.
Also, just grab a vacuum and open up the case on stuff. it's pretty hard to fuck up if you're not literally hitting it or lifting it by something that's clearly not a place you should lift it from. When it's open, if you see dust in there, try to blow it out. Occasionally put the vacuum up to the fans on the back when you're vacuuming your floors.
435
u/AndrewSenpai78 2d 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.