Who says using a ton of RAM isn't efficient? Unless your system OOMs what's the downside of having a bunch of allocated memory? Especially if it isn't even paged in.
Several reasons why this principle doesn't apply in this specific (Electron) situation:
(1) Every single Electron/webtech application I've used hasn't just consumed tons of RAM, but also had a noticeable CPU (-> battery & performance) impact.
(2) Most webtech apps I've seen have had memory consumption in the 200-400 MB range - which isn't a problem on my 16 GB desktop, but is a problem on my 4 GB RAM laptop. People have less RAM than you think, and want to run more applications than just yours. Which is better: to be able to run Spotify, Discord, Slack, Matrix, Obsidian, your web browser and a video game all at once, or to have to manually open and close applications when you OOM?
That is - wasting 200 MB of RAM isn't bad if your available RAM is far in excess of 200 MB. For most people, it isn't. If Electron apps each used only 5 MB more than necessary, you would see virtually no complaints at all.
(3) Inefficiency is making bad use of available resources. Not only are chat applications like Slack and Discord not intrinsically difficult problems, but the very existence of third-party clients like Ripcord[1] show that these applications are making extremely poor use of the resources given.
Memory is a limited resource to be used judiciously, not an all-you-can-eat buffet.
At the end of the day, if my system wildly misbehaves under high memory pressure, and forcing the pressure down resolves the misbehavior (or keeping a certain amount of headroom prevents it from happening outright), "linux ate my ram" is an accurate description of what happened and no amount of tut-tutting telling me that it doesn't work the way I just got done seeing it work changes that.
I'll give zram a try, but the problem here is poor usage of memory (both in priority and badly-behaved bloatware), not quantity of memory available. I'm not a kernel developer, I shouldn't have to dork around with these kinds of knobs to get sane behavior.
Worse, this often happens when there's plenty of cache to evict. I can and have restored a nigh-unusable desktop to normal operation many times with a painfully entered `echo 3 > /proc/sys/vm/drop_caches` from a new TTY, instantly resolving the pressure and giving me time to find and terminate the presumptuous program who thinks its entitled to 3/4 of system memory (usually some flavor of web browser or electron bloatware).
Why's the kernel so jealously guarding its cache allocation and making the UX suck harder? Not a clue. Whatever performance penalty I take from nuking caches is far, far less than from allowing free memory to fill up and dealing with the pathological behavior surrounding that.
Just to again note that just because a program says it's using N MB of RAM doesn't mean that all of that RAM is actually paged in. Every thread you execute has an 8+MB stack but most of it won't get allocated for the majority of programs.
> we start digging into swap, and at that point, the UI is starting to significantly chug.
Only if you're constantly swapping in and out of swap. Just putting something into swap and never retrieving it won't case issues.
I'd generally recommend disabling swap altogether though and just letting OOM take out misbehaving processes.
This isn't all to say that using less memory is 'bad', but when people say 'oh that program is such a memory hog' I wonder if they might be measuring incorrectly, or not realizing what it's doing with that memory.
Which, in the experience I just gave, is what's happening. System memory at some high 90s percent utilization, swap usage creeping up, kswapd with a ton of CPU usage, and worst of all, UI chugging. If it wasn't 'actual' memory usage, why does dropping caches, instantly freeing up some amount of memory, restore responsiveness?
I've tried operating swapless before, but that just means OOM killer kicks in even when there's cache to evict. That seems like a priority inversion to me - of anything paged in, shouldn't cache have the absolute lowest priority, and be the first thing to go when memory's needed for other things?
Besides, memory usage is hard to measure. Lots of memory may never get paged in.