4 ms·

Isn't the point of having RAM to fill it in order to cache objects? To me measuring how much RAM a DE uses is strange because I would expect it to consume enoug

by Matl 4y ago

Isn't the point of having RAM to fill it in order to cache objects? To me measuring how much RAM a DE uses is strange because I would expect it to consume enough RAM to be snappy but be able to adopt in a constrained system. If however I have 8G free, use it away, I don't see the point in having RAM I paid for sitting around unused.

thfuran 4y ago
If the desktop environment is consuming all the RAM to eek out a bit of extra performance, then it's not available for the applications to do the same.
- Matl 4y ago
  Ok, so to be precise I did not mean to imply a DE should be a resource hog, leak memory all over the place etc. I simply meant to say that a diff of few tens or even hundreds of MBs of RAM between DEs is realistically insignificant for most people.
lucideer 4y ago
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.

by Matl 4y ago

thfuran 4y ago

If the desktop environment is consuming all the RAM to eek out a bit of extra performance, then it's not available for the applications to do the same.

Matl 4y ago
Ok, so to be precise I did not mean to imply a DE should be a resource hog, leak memory all over the place etc. I simply meant to say that a diff of few tens or even hundreds of MBs of RAM between DEs is realistically insignificant for most people.

lucideer 4y ago

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.