3 ms·

Oh yes. I've seen that in my day job where a current project is a custom ASIC with a luxurious 1 megabyte of RAM. At the beginning of the project we were all o

Oh yes. I've seen that in my day job where a current project is a custom ASIC with a luxurious 1 megabyte of RAM. At the beginning of the project we were all optimistic, and people spent RAM with wanton abandon. But kilobyte by kilobyte, allocation by allocation, function by function, we started running into those limits for both code and data. 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.

owalt 4y ago
I work on a <500kB RAM embedded project currently (and similar constraints in previous ones), and I can pretty much mirror what you said. The current project is in the planning/early development phase, and it's like everybody forgot the multi-month entire-app refactors we had to do twice to save some small fraction of total RAM in the previous project. But when you're pushing for another release with another too-tight release schedule, suddenly RAM savings are not an immediate but a future problem. 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?

owalt 4y ago

I work on a <500kB RAM embedded project currently (and similar constraints in previous ones), and I can pretty much mirror what you said. The current project is in the planning/early development phase, and it's like everybody forgot the multi-month entire-app refactors we had to do twice to save some small fraction of total RAM in the previous project. But when you're pushing for another release with another too-tight release schedule, suddenly RAM savings are not an immediate but a future problem. 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?