4 ms·

That's the point at a holistic level, but in reality it's a shared resource. A DE in particular is never the primary application - it should spend most of its t

That's the point at a holistic level, but in reality it's a shared resource. A DE in particular is never the primary application - it should spend most of its time largely invisible to the user - so using a lot of RAM that actual applications may require would not be my expectation. > be able to adopt in a constrained system That's a fair caveat, but in reality no software is perfect & there's often a trade-off here. Being conservative with RAM usage in general (instead of trying to be both greedy & adaptive) is a much more prudent approach. The latter is ideal, but hard to achieve perfectly. Working on being reasonably good at both is going to give you the best quality outcomes. > I have 8G free, use it away, I don't see the point in having RAM I paid for sitting around unused That's a nonsensical sentiment. What's the point in using RAM "you paid for" for something useless/wasteful - you're not getting your money's worth whether the RAM is idle or wasted.

horsawlarway 4y ago
So at least for Gnome - the general strategy they appear to be aiming for is "Use it if you've got it, give it back if you're running low". Which - is entirely reasonable, in my opinion. > That's a nonsensical sentiment. What's the point in using RAM "you paid for" for something useless/wasteful - you're not getting your money's worth whether the RAM is idle or wasted. It's not being "wasted" it's resulting in faster IO for anything that happens to be in it. Given the choice of having your RAM full or empty... you should pick full every time. You just need to make sure that "full" can be adjusted to make space for whatever application you might want to open next. So... swinging back around to Gnome - as far as I can tell, they're trying to do exactly that (full disclosure, I can't speak for how well this is adopted). The blog post outlining the goal is here: https://www.hadess.net/2019/12/gmemorymonitor-low-memory-monitor-2nd.html https://www.hadess.net/2019/12/gmemorymonitor-low-memory-mon... The implementation and docs are here: https://docs.gtk.org/gio/signal.MemoryMonitor.low-memory-warning.html https://docs.gtk.org/gio/signal.MemoryMonitor.low-memory-war...
- lucideer 4y ago
  > "Use it if you've got it, give it back if you're running low". > You just need to make sure that "full" can be adjusted to make space for whatever application you might want to open next. > full disclosure, I can't speak for how well this is adopted This is the issue I'm highlighting. This is what everyone tries - engineers are one of the most vulnerable breeds to overestimating their ability to achieve an ideal plan. It rarely if ever works perfectly, and very often works sub-optimally to the point of significantly hampering overall system performance. I don't know that Gnome abjectly fails in this goal, but I do know that it's not fast. It's significantly slower than other projects with comparatively much less engineering resources behind them. For some reason. > It's not being "wasted" it's resulting in faster IO for anything that happens to be in it. Given the choice of having your RAM full or empty... you should pick full every time. This is absolutely wrong, because you're basing this all on the assumption that if it's not in RAM it'll be loaded from disk. In other words, the assumption that "it" needs to exist in the first place (&/or needs to be the size that it is). This is really disingenuous: when people talk about RAM-hungry apps and wastage they're never targeting optimistic IO (good) they're targeting large unnecessary data being accessed at all. Good low-RAM apps don't load excessively from disk. They use less data. They have more efficient raw resource handling & execution paths in the first place. An emphasis on engineering systems that effectively & efficiently release RAM when needed elsewhere focuses person-hours on improving (very complex) pieces of logic that wouldn't be as necessary if said person-hours were instead focused on making those resources being loaded smaller / less numerous.
  - horsawlarway 4y ago
    > They use less data. And generally they do that by offering fewer features (and yes - aesthetics and ergonomics are features!). By the time I'm installing Gnome/KDE... I've already picked a heavy DE - I want it to be extensible (js/css in gnome is pretty great), pretty, and fast on a modern machine. I'm not picking those DEs for a constrained environments. In those envs - I may well just skip the DE although, or go with something lighter like Sway. But when I have 32gb of RAM... I really would prefer the feature rich DEs continue to focus on features when the usage is ~6% of RAM (2/32's). The RAM is, all things considered, outrageously cheap compared to their dev team's time. When I want to conserve RAM... I'll pick a different tool.

horsawlarway 4y ago

So at least for Gnome - the general strategy they appear to be aiming for is "Use it if you've got it, give it back if you're running low". Which - is entirely reasonable, in my opinion. > That's a nonsensical sentiment. What's the point in using RAM "you paid for" for something useless/wasteful - you're not getting your money's worth whether the RAM is idle or wasted. It's not being "wasted" it's resulting in faster IO for anything that happens to be in it. Given the choice of having your RAM full or empty... you should pick full every time. You just need to make sure that "full" can be adjusted to make space for whatever application you might want to open next. So... swinging back around to Gnome - as far as I can tell, they're trying to do exactly that (full disclosure, I can't speak for how well this is adopted). The blog post outlining the goal is here: https://www.hadess.net/2019/12/gmemorymonitor-low-memory-monitor-2nd.html https://www.hadess.net/2019/12/gmemorymonitor-low-memory-mon... The implementation and docs are here: https://docs.gtk.org/gio/signal.MemoryMonitor.low-memory-warning.html https://docs.gtk.org/gio/signal.MemoryMonitor.low-memory-war...

lucideer 4y ago
> "Use it if you've got it, give it back if you're running low". > You just need to make sure that "full" can be adjusted to make space for whatever application you might want to open next. > full disclosure, I can't speak for how well this is adopted This is the issue I'm highlighting. This is what everyone tries - engineers are one of the most vulnerable breeds to overestimating their ability to achieve an ideal plan. It rarely if ever works perfectly, and very often works sub-optimally to the point of significantly hampering overall system performance. I don't know that Gnome abjectly fails in this goal, but I do know that it's not fast. It's significantly slower than other projects with comparatively much less engineering resources behind them. For some reason. > It's not being "wasted" it's resulting in faster IO for anything that happens to be in it. Given the choice of having your RAM full or empty... you should pick full every time. This is absolutely wrong, because you're basing this all on the assumption that if it's not in RAM it'll be loaded from disk. In other words, the assumption that "it" needs to exist in the first place (&/or needs to be the size that it is). This is really disingenuous: when people talk about RAM-hungry apps and wastage they're never targeting optimistic IO (good) they're targeting large unnecessary data being accessed at all. Good low-RAM apps don't load excessively from disk. They use less data. They have more efficient raw resource handling & execution paths in the first place. An emphasis on engineering systems that effectively & efficiently release RAM when needed elsewhere focuses person-hours on improving (very complex) pieces of logic that wouldn't be as necessary if said person-hours were instead focused on making those resources being loaded smaller / less numerous.
- horsawlarway 4y ago
  > They use less data. And generally they do that by offering fewer features (and yes - aesthetics and ergonomics are features!). By the time I'm installing Gnome/KDE... I've already picked a heavy DE - I want it to be extensible (js/css in gnome is pretty great), pretty, and fast on a modern machine. I'm not picking those DEs for a constrained environments. In those envs - I may well just skip the DE although, or go with something lighter like Sway. But when I have 32gb of RAM... I really would prefer the feature rich DEs continue to focus on features when the usage is ~6% of RAM (2/32's). The RAM is, all things considered, outrageously cheap compared to their dev team's time. When I want to conserve RAM... I'll pick a different tool.