Hacker News Reader

Comment by userbinator | Hacker News Reader

Going from over 46MB to under 12MB seems impressive on a relative scale, but if this is the code of the "dotnetapp-selfcontained" example,

https://github.com/dotnet/dotnet-docker-samples/blob/master/...

That is still, absolutely speaking, twelve million bytes for not much more than "Hello World" levels of functionality, which means there remains plenty of room for improvement. I estimate the lower limit for this particular app is somewhere in the hundreds of bytes, most of it being string constants.

View on HN

I see this fallacy repeated often. "Hello World is 12 MB - just imagine how big a real app will be!!!"

Hello World doesn't benefit from that 12MB. Your real app would.

12MB is not for Hello World. 12MB is for Hello World + Common Language Runtime (garbage collection, bounds checking, memory protection, execution environment etc.) + the .NET standard libraries (LINQ, task parallel library, etc.)

You're probably going to need those things in a real app.

If you're actually doing Hello World -- and that is all you're doing -- and if using 12MB of your 16GB of RAM is unacceptable for you, yes, by all means write some native code.

Put another way: what should be left after linking is just the parts of the CLR + BCL that the runtime needs to function. Apparently that takes 12MB today. There is a JIT, GC and Execution Engine all in there.

The number might shrink as the linker gets more aggressive but i wouldn't count on it much.

The application IL code is perhaps 50 bytes to for hello world.

12 megabytes doesn't sound too bad for the things you mentioned, especially if it's a constant cost.

> The application IL code is perhaps 50 bytes to for hello world.

A Hello World assembly in .Net Core 2.0 is 4.5 kB.

Out of that, the IL is 11 bytes, though that doesn't even include the "Hello world!" string.

I see this fallacy repeated often. "Hello World is 12 MB - just imagine how big a real app will be!!!"

You're probably going to need those things in a real app.

I'm not saying that. From the page itself: "The linker removes code in your application and dependent libraries that are[sic] not reached by any code paths. It is effectively an application-specific dead code analysis"

Going by that description, Hello World should be the most trivial of test cases for removing unneeded cruft, and yet it still leaves plenty behind.

Also, don't assume that everyone has 16GB of RAM (I have a tiny fraction of that), or that even if they do, your app should be using all of it.

The answer is in the quote "The linker removes code in your application and dependent libraries...". That doesn't include the Common Language Runtime.

Excellent point. There are two major caveats today:

- no removal of native code. - no removal of code from the base managed assembly.

We would like to fix both and both are a large win.

Reply on news.ycombinator.com