>1 gig of ram for a gui is fine because ram is cheap I know because I program C++ and 1 gig is 6% of 16.
I don't know why you needed a paragraph to say that 1000% memory inflation is a trade-off to optimize dev costs and we can just ignore JS because our goal is to support a browser as the gui.
It's a bunch of nonsense and yet you call what I said nonsense while all you do is provide opinion that it's OK because trade-off or something. What you said is purely opinion so you can't say my take is nonsense. There's nothing "pure engineering perspective" about it.
> I don't know why you needed a paragraph to say that 1000% memory inflation is a trade-off to optimize dev costs
Because that's not what I said. My point was more that a "1000% memory inflation" is not a meaningful cost metric to begin with (to use just one toy example, perhaps you'd agree that going from 10% RAM to 100% has a very different impact than going from 1% to 10%, even though both are a "1000% inflation").
Memory (at least on a personal computer) is not rented by the hour on a per-MB basis; you buy it in bulk. What matters isn't how much memory you could have used but what you'd use the "saved" memory for. Also, when you buy a resource like RAM or CPU as a package, nominal values matter less than under what conditions one of these would reach 100% and your experience may be degraded.
For example, if you have 16GB of RAM and you only ever run one program at a time, it doesn't matter to you at all if it uses 3GB or 3MB: you've paid for 16 and the total savings of the 3MB app are zero and in this hypothetical case, there's no tradeoff at all. Now, the average user on the average hardware doesn't use only one GUI app at a time, but they're also not using 200. The only relevant question pertaining to waste is what is the value of 3% memory to your users (integrated over all of them)? In many situations (again, not all), the answer is not much. (And BTW, some developers seem to care about 3% memory more than they do about 3% CPU, even though CPU is much more expensive).
When it comes to agent harnesses, the analysis is clearer. On the one hand, people using coding agents are more likely than others to put even a little extra free RAM to some good use, but on the other hand, the cost of using the models themselves is so high that it makes the cost of RAM for the GUI negligible.
Saying that a number going up by 1000% is bad is not good engineering. Good engineering requires thinking about the actual value and cost of that number. It varies over time, over app type, over different types of users, and over different kinds of deployments (i.e. how RAM is packaged and paid for).
That doesn't make sense. If the cost of RAM is high and being used by models then yes, you should try to use less RAM. Using opposite logic is not good engineering. Seriously, what kind of argument is that? Hahaha
I'm entertaining this nonsense because I want to clarify, that I use a 20 year old web gui and it consistently eats 8 gigs of ram in Webkit because it uses CSS to update the forms. Webkit is the only option on iPads and yet it can't handle a 20 year old website because it doesn't do things in the standard ways. It's ridiculous to say "why doesn't it target web" especially after someone presents new coding harness that went out of its way to run well without it.
> That doesn't make sense. If the cost of RAM is high and being used by models then yes, you should try to use less RAM.
No, that's not the conclusion. If using models costs you, say, $10 an hour, and a GB of RAM costs you, say, $0.0001 an hour, then clearly you shouldn't spend your time on reducing the insignificant cost if you want your work to deliver the most value to users.
But again, "less RAM" is more or less meaningful whether you're reducing the RAM usage from, say, 5% to 1% or from 80% to 40%. The latter is more valuable even though it's a lower relative reduction. That's because what the users care about is in what conditions they reach 100% of either CPU or RAM, and the second 2x reduction, therefore, offers more value than the first 5x one. This is similar to how a 10% discount on a car offers far more value than a 99% discount on a pack of chewing gum. This is still the case if you're buying 100 packs, but maybe not 10,000, and the same goes for software: it may also matter how many copies of the app the user is expected to run concurrently. The point is that you can't assign a value to a 10x reduction if that's all you know.
> I'm entertaining this nonsense because I want to clarify, that I use a 20 year old web gui and it consistently eats 8 gigs of ram in Webkit because it uses CSS to update the forms.
And I'm entertaining this nonsense because you're clearly not a very experienced engineer and you may learn something. In the ninetees, when nearly all GUI apps were written in C or C++, we had plenty of examples where a C++ GUI app consumed 50% RAM. That doesn't mean that C++ is worthless, only that some software has serious resource bugs, and it sounds like that web page you're referring to is a case of that. Most web-based GUI apps today do not consume a higher portion of RAM than their C++ counterparts did 30 years ago. Today's browser-based MS Word consumes less (relative) RAM than the C++ version did in 1998, and it certainly has a far smaller negative impact on concurrently using other apps on the machine.
And, of course, there are buggy/leaky programs now just as there were then. It's silly to say that the existence of such programs means that the approach is bad, because that would apply to any sufficiently-popular language or toolkit.
Anyway, our job is to offer the most value to our users, and reducing RAM consumption by 3% or even 5% (of available RAM) is usually not where you'd find much value.
Oh ok, good, because we're talking about reducing RAM two orders of a magnitude, as addressed in the article. Good talk.
Yes, except we're not talking about reducing 100GB by two orders of magnitude, but about reducing 1GB of mostly inert RAM by two orders of magnitude, otherwise known as freeing up low single-digit %RAM, and in this case we're talking about doing that for software that, every month, could cost as much as your entire machine's RAM.
vs code only uses about one gigabyte when nothing is loaded, but you should have about about 16 GB. I'm sorry were you using VB6?
I'm primarily a low-level C++ systems programmer, and most of my work has been in soft- and hard-realtime apps and runtimes (which is why I'm so sensitive to the RAM issue, because in my world it's extremely important to optimise the metrics that matter, because optimising things that matters less hurts you, and so we spend a lot of time figuring out which metrics matter and when) but yes, I recall using VB6 or Access for some internal management apps.
VS Code might be using close to 1GB with nothing loaded, but it doesn't go much higher with stuff loaded, at least not that I've noticed. I do have 16GB because that's what you get in a laptop these days, and I'm always running at least three Electron apps concurrently, a browser with about 200 open tabs, and then another one or two browser with a few tabs each (plus an email client, and of course, agents and compilers running in the background). The only time I notice an issue is when a program leaks memory.
But again, I try not to look at numbers unless I know exactly what their effect is, and I rarely if ever notice any ill effects caused by well-behaving Electron apps, and unless I notice an actual problem I try not to look at numbers, because they can lead you down the wrong path and distract you from what actually matters. Overall RAM in particular, especially when combined with low-CPU (which makes swapping cheap), is a very misleading metric because it's not easily translatable to value without lots of other pertinent information (such as how many copies of the program the average user is expected to run concurrently, how many other programs the user is expected to run and what the CPU utilisation is).
In the nineties and early oughts, I, like many other developers, obviously focused a lot on reducing RAM because it mattered a lot under the conditions back then. Over the years, it started mattering less and less, to the point that you need a very clear justification to optimise it (in fact, you need a clear justification to optimise anything, or you'd end up wasting your time on optimising the wrong thing at the expense of the right thing). These days, I too often see developers trying to reduce RAM without being able to point at an actual (not hypothetical) user-experience problem they're solving.
[flagged]