Ask HN: Why is the hunger for RAM never satisfied?
Throw 16GB at a system and start up a few browsers and other programs, and pretty they have used up almost all the RAM. It seems browsers in particular will happily eat all the RAM they can.
Why is this? At what point will the hunger of apps for RAM be satiated? With 32GB? 64GB?
With all the advances in tech, why are our hardware still struggling to keep up with demands of the apps we use?
82 comments
[ 2.8 ms ] story [ 34.6 ms ] threadImaging getting an OS message "sorry, even though your computer has 12 more GB of ram available, this program has used its max. Allow more?" people would ask for this message to be disabled and the allow more Yes option be the default.
There is no free lunch, everything has a price. If you want to have fast, very efficient software, you will have to optimize it for the hardware, which will cost development time. It also may or may not be maintainable.
Or you can use an all-in-1 solutions, that will handle everything in all (most) situations. It will be relatively fast to develop with, but the result will be far from efficient. It will be "good enough" for the current hardware.
As long as hardware is cheaper than developer time, this trend will not stop most probably.
(On a personal note, this is my favorite thing about embedded software: developers are forced to use hardware efficiently, which can result in surprisingly fast code - at least surprising when compared to regular bloatware)
Getting less true in low-volume embedded, where you can now throw a few ARM cores (or now RISC-V) and GBs of RAM at it for just a few dollars extra.
The payroll and time-to-market costs of paying embedded developers to lovingly massage and squeeze the application into the smallest device possible to save on the BOM don't start to pay off until you're shipping a lot of units.
"nobody does that" times 20 years of RAM getting ever bigger, ever cheaper; and you get where we are today.
Once upon a time, emacs was considered a hog: "Eight Megabytes And Constantly Swapping". We had to invent whole new layers of indirection and waste to come up with the current VScode type efforts.
"the hunger of apps for RAM" will never be satisfied, just like there will never be no books for the printing presses to print: We'll find some use for keeping the machines thrashing no matter how silly.
Seems unlikely, but at some point it might make sense. Of course if the resources (electricity, silicon, etc.) required by developers to implement such efficient code exceeds the estimated savings, then doing it would actually be worse. But think about all the build scripts constantly being invoked, for example. The energy used to develop them must be extremely overshadowed by the energy to execute them.
> Software used by a certain minimum number of users, and software used in certain fields (like medicine, transport, and finance) need to be subjected by regulatory agencies to certain objective (hence automated?) tests to ensure they meet some minimum reliability, usability, security, and performance requirements. In this regime, small-time SaaS software, or hobby projects, would not need any regulation, but flagship software products of Facebook, Google, SAP, Oracle, Tesla, etc would need it.
When you're in a custom ASIC though, there is no "just plug more RAM in", so I've had to jump through hoops to eliminate excessive allocations and push to other parts of the system the computations that require significant scratch space. But it all takes time and effort. The last two major refactors that restored our buffer took 6 months to complete. They did nothing to improve system functionality, they just bought us the space to implement new features.
That's a lot of developer time to burn for something that will help in the future, but isn't delivering value now.
And that's undoubtedly why we're always in a RAM crunch. We value tools for the speed in development and flexibility, but do not care about how much storage or power they waste. Otherwise JavaScript wouldn't be running the web.
For us the day will come where we atone for our sins and have to again put off feature updates for months of RAM optimization. But in the PC/server/mobile space, that day gets pushed off whenever people move on to better hardware. So why not continue to bloat your applications, really? There's little incentive to do otherwise. If clunky abstractions make your developers ever so slightly happier, what's the reason not to embrace them?
My work isn't the best out there in that regard, but by simply making the more obvious optimizations as you go you're already doing better than the majority, and I'm confident that any effort beyond that puts you in the top 10%.
“Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.”
There’s a comparable race between hardware engineers striving to build faster and more capacious systems and programers blithely consuming all the cpu and memory they can find. So far, the programmers are winning that one.
I guess our desires to have plenty of RAM available are secondary to our desires to have 100 tabs open at once, a quarter of which have a ton of sophisticated JS behavior, and never lose application state in any of them. Oh well.
You could always look at this the other way - I did pay for that 32GB of RAM, why shouldn't it be actively used for things I find at least sort of useful instead of staying forever unused in support of some abstract notion of how being paltry with RAM use is good, or for some possible other task I want to do that does need lots of RAM.
Certainly other apps could do better. But I've made peace with the fact that browsers and IDEs, for instance, should use as much as I have available because the whole point is for them to be fast and to be fast they need to cache as much data as possible.
Firefox got to a point where it was consuming 24 GIGS OF RAM, yes, 24, on my 32GB of RAM machine, and you'd say oh but that's still okay, your PC should function properly, nope, once it starts leaking FF starts hogging your PC, even at like 8GBs of RAM it's already hogging the PC.
I don't really know what's going on but FF mods on reddit and such are on denial and gaslight you about it, it's been this way on several operating systems (windows 10 and now 11) and with or without addons (not like I use any special addon, really, just basically Ublock, although now I've started using clickbait remover, sponsorblock and bypass paywall).
For the same amount of tabs open Edge and Brave for example use like 3gbs or less of RAM, even after months.
And here I thought all major browsers have implemented the feature where unused tabs are unloaded from memory after some time.
I use fvwm and it is far from fancy, but it gets the job done and is quite efficient.
Proprietary software Companies discovered early on eye-candy sells, and many people in the Linux Land is following what Apple and Windows developers do because most people want a similar fancy look.
In many cases PCs and Laptops are more of an entertainment device as opposed to a data processing device, that means Browsers are getting lots functionality for that use-case, and that is not cheap.
I had hoped the move of the masses to Cell Phones and Tablets would stop this trend, but seems it only to have accelerated it.
Now a "rant"
On the Linux side, Wayland is a big concern for me because I may be forced into using software that has a lot of functionality I do not need, stealing RAM from processing/analyzing large sets of data that could use gigs of RAM.
Right now my distro of choice still easily allows me to avoid that bloat, but the Wayland move may force it to follow to use something Red Hat created that to me is way to complex and is overkill.
Luckily OpenBSD and NetBSD (on a BSD now) is trying to avoid that mess, but Wayland may force changes I believe neither of these systems wants. Adding the bloat these systems have been able to avoid. Already dbus is needed for Firefox/chrome... What else will they be forced to port.
Web browsers especially have become full of problems. It lacks better controls that the end user can customize and link with other programs etc, and is full of bloated features that don't help and often make it worse anyways. Unfortunately, WWW is a mess, I have some ideas for improvement which are unfortunately still need to be a mess a bit but still can be somewhat better; some of the specifications could be "turned around" to be implemented more usefully for the user instead of the author, e.g. a request/response overriding configuration can substitute for many of the other settings, etc. ARIA might also be helpful in some cases.
I also don't like Wayland, and I don't like Unicode either (what someone mentioned is that Unicode makes text processing very slow; apparently that is even worse than I thought). There are parts of the Freedesktop specification which are problematic, in my opinion, too (as well as some parts which are unnecessary but can be avoided).
And then there are sandboxing systems to try to improve security, but they have problems too, such as requiring file names to be Unicode (you can't use EUC-TRON), and having rather limited functionality with allowing end users to connect them with other programs, e.g. it does not seem to have a way to ask the user for a command which will be executed by popen. And then, you might want permissions to differ by command-line switches, etc, and that is also difficult. (I do have idea how to make a better one, though.)
Those who are trying to avoid this bloat should make packages which are designed to reduce it by making programs (modifying existing ones if necessary, and avoiding certain dependencies, including the most common web browser engines) without D-bus, Wayland, systemd, etc.
An operating system with capability-based security (including proxy capabilities too) also would be a good idea, I think. (I have some ideas relating to operating system design; maybe some other people will be able to help with this too)
At least, it is what was intended, but it has many problems. You can do international text without it. Unfortunately, it is also used for fancy decorations too. One possible alternative is TRON code, although usually it would be to not to force character encoding on programs that don't need them.
With Unicode, there is then duplicated work of validation, etc, which can both cause some data to be lost and can slow it down because it does things redundantly, etc. It tries to display text using mixed directions in a way that isn't very good, etc.
The other big thing is I never have more than 4-5 tabs open--anything beyond that just bookmark the sites and come back later, having hundreds of tabs open is just silly and a true anti pattern for research and thinking.
2) writing streaming code is harder
I guess it would also explain why the games I would write in 2011 on a netbook ran so smoothly on every other computer I tested them on, despite using the legacy OpenGL 1.1 API, etc. etc.
Weird,
8/16 GB of RAM were common configurations for at least last 10? 15? years.
RAM advances very, very slowly in compare to e.g disks, gpus and cpus.
There were Optane memories which had way higher amounts of RAM, but they're cancelled as far as I've heard.
Personally the only time I'm constrained by memory is when running Windows VM in the background.
But if I didn't have 20 apps running in the background (web browsers/games/IDEs/chats/etc) then it wouldn't be a problem, I think.
Our computers are doing more and more tasks, we want to have answers faster and without using internet bandwidth, so there's a lot of caches and having stuff in the memory
Plus we're just victims of our own technological success. RAM is cheap. Similar to all the old classic cars from the 60s, gas was cheap, engine tech advanced and environmental regulations nonexistent, so you got giant 7L V8 engines running at like 10 mpg even with premium, leaded gasoline. It wasn't until pollution regulation, gas taxes to pay for infrastructure, and now climate change (in some peoples' minds) that efficiency became a priority.
Maybe that's even a bit too pesimistic. Cloud computing already gives companies incentive to focus on efficiency for cost saving and there is a growing trend to write simpler more performant software to replace existing tools, however not specifically in the general purpose computing space.
There are programs out there that are RAM-efficient. Every single one was written by someone that DOES care and ISN'T lazy.
Back when RAM was $25 per KILObyte*, that saying was reversed. "Programmer's time is cheap and RAM is horribly expensive." Especially when there were hard limits to the RAM as in 8-bit computing where the hard limit was 64 kilobytes of contiguous RAM. Programmers used to sweat over saving bits, even, hence the packed-data systems where you might fit (say) 3-bytes of data into two bytes by squeezing out redundant bits.
=========
* That doesn't sound particularly expensive till you compare it with today's costs. $25 per KiLObyte = $25,000 per MEGAbyte = $25 MILLION BUCKS per GIGAbyte.
Seeing my current computer that I'm writing this on has 32 gigabytes of RAM, that amount of RAM would have cost me Eight Hundred Million (non-inflation-adjusted) Bucks back in 1980. (And I haven't bothered to adjust with the 'kilo' = 1024 factor out of pure laziness)
It's common for consumer software to use 10, 100, or even 1000 times as much memory as is needed. If that forces every user to buy $200 of extra RAM, it is definitely more costly than developer time.
Besides, what else is developer time getting spent on? Take Slack for example. For the past 8 years or so, Slack -- who employs thousands of engineers, mind you -- has spent developer time on two things: 1) breaking the UI for no reason, and 2) reducing memory usage. Only one of those things has benefited me as a user!
The value added of using less RAM for a single application that you develop is close to zero, so people don't do it; if all other apps on that computer use hundreds of MB to several of RAM, your reduction from 100 MB to 5 MB is insignificant for the overall system. When everyone thinks the same, you just buy another 16 GB of RAM and everyone's messy app will fit. Developers know RAM is cheap, but don't calculate the result of cheap multiplied by millions (not cheap at all).
The only 2 times developers think about RAM consumption is when they design an application and set a target and then when they go to testing and exceed the target, so they need to reduce it enough to pass. If the design review allows them to set a relatively high target, they don't have to care at all.