5 ms·

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

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.
  - lucideer 4y ago
    > And generally they do that by offering fewer features (and yes - aesthetics and ergonomics are features!). XFCE has more features than modern Gnome. Aesthetics comes from GTK, which it uses. Ergonomics is better in Gnome, largely due to consistency, which I'd attribute to Gnome's development effort: more people to work on more coordinated behaviours across apps & integrations - XFCE borrows small parts of Gnome's work while also using a patchwork of other solutions from elsewhere; an approach which detracts from the UX. This is about engineer resourcing though, not engineering approach to performance. The latter is an independent variable. There's nothing "heavy" about Gnome aesthetically of feature-wise except the general inefficiency of its implementations. Especially feature-wise in its latest incarnations: ever since the Unity/Shell split &c., the Gnome featureset as contracted significantly from what it once was. > I want it to be extensible (js/css in gnome is pretty great) What's great about it specifically? It's unrealised potential? Gnome's extensibility is a graveyard. The pace of API changes (another code smell when it comes to engineering approach), compared to the tiny level of community contribution of Shell extensions means most of those available for download are broken. Those that work are minimal / have inconsistent UX / no docs. If you've got to write your own code to customise the thing anyway, why not just use a more esoteric highly-customisable DE in the first place?
    - horsawlarway 4y ago

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.
- lucideer 4y ago
  > And generally they do that by offering fewer features (and yes - aesthetics and ergonomics are features!). XFCE has more features than modern Gnome. Aesthetics comes from GTK, which it uses. Ergonomics is better in Gnome, largely due to consistency, which I'd attribute to Gnome's development effort: more people to work on more coordinated behaviours across apps & integrations - XFCE borrows small parts of Gnome's work while also using a patchwork of other solutions from elsewhere; an approach which detracts from the UX. This is about engineer resourcing though, not engineering approach to performance. The latter is an independent variable. There's nothing "heavy" about Gnome aesthetically of feature-wise except the general inefficiency of its implementations. Especially feature-wise in its latest incarnations: ever since the Unity/Shell split &c., the Gnome featureset as contracted significantly from what it once was. > I want it to be extensible (js/css in gnome is pretty great) What's great about it specifically? It's unrealised potential? Gnome's extensibility is a graveyard. The pace of API changes (another code smell when it comes to engineering approach), compared to the tiny level of community contribution of Shell extensions means most of those available for download are broken. Those that work are minimal / have inconsistent UX / no docs. If you've got to write your own code to customise the thing anyway, why not just use a more esoteric highly-customisable DE in the first place?
  - horsawlarway 4y ago