Hacker News Reader

Comment by DaiPlusPlus | Hacker News Reader

> 1,135,948k of memory

That's 1.1GB.

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.

(Historical personal anecdote: my first-ever dev-server machine I built before high-school ran Windows Server 2003, IIS, SQL Server, and Adobe Photoshop 7.0 (in a Terminal Services session) concurrently just fine well-within 256MB with little-to-no paging)

Let's be generous and assume that 64MB should be a reasonable upper-bound (though I think that getting it under 16MB should be possible), in which case what exactly is the other 1.09GB of RAM being used for?

View on HN

I'm not entirely sure on this, but I believe that what we're seeing is the WASM runtime allocating memory for its potential needs, but not totally using it all.

The entire filesystem, all the executables, all uploaded files, and all database data lives in memory in the virtual filesystem. I think we could trim down the default allocation but it might actually be meaningless anyway; that GB won't steal real RAM unless it fills up inside the environment.

Someone can probably check me on this, but if my memory serves me right this is what's going on.

In like 1997 I was doing some work with a 5x86-133 with 24mb ram and a 2gb disk, running NT 3.51, MS SQL server, IIS and Visual Studio 4. IIRC, the servers usually ran in less than 500kb committed each.

> 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.

Difficult to say without proper debugging tools. Chrome dev tools seems to cause it to not run for me.

> in which case what exactly is the other 1.09GB of RAM being used for?

Wrong answers only?

Caching alternate data streams

Dr. Watson

McAfee antivirus

Reply on news.ycombinator.com