> That's horrifying because, theoretically, it should be a tiny, tiny fraction of that: on bare-metal we can run PHP + MySQL (let alone SQLite) + Apache within a few dozen MB of RAM
Only being half-facetious here: if the old stack was so great, why aren't you still using it? I know someone who swore by ColdFusion, but won't use BlueDragon or Lucee because the world has moved on from CFML; templated HTML-generation on the server is no longer the only game in town
> if the old stack was so great, why aren't you still using it?
I am, granted, current-versions-thereof - though with more recent OS versions the RAM requirements just go up, because modern OSes (especially Windows Server) are built to more aggressively cache things in RAM to avoid paging to disk.
I work primarily in .NET and that is also RAM-hungry: it allocates a huge chunk of RAM for each CPU core for per-thread GC purposes - which does drastically improve GC perf in production - and if prod has only 1-4 VM cores assigned this isn't a problem - but on my dev box with its 24-core Xeon CPU it means even a Hello World program will consume probably 500MB+ of RAM - ugh. To-date, I haven't found a way to control or limit this.
But my post wasn't me complaining about my current situation - more about my despair at the lack of belt-tightening from certain platform vendors like Chromium - or in this case, why compiling to WASM instead of native results in this level of RAM usage.
Only being half-facetious here: if the old stack was so great, why aren't you still using it? I know someone who swore by ColdFusion, but won't use BlueDragon or Lucee because the world has moved on from CFML; templated HTML-generation on the server is no longer the only game in town