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