3 ms·

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 ap

by judah 9y ago

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.

algorithmsRcool 9y ago
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.
- Kuraj 9y ago
  12 megabytes doesn't sound too bad for the things you mentioned, especially if it's a constant cost.
- svick 9y ago
  > 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.
userbinator 9y ago
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.
- openasocket 9y ago
  The answer is in the quote "The linker removes code in your application and dependent libraries...". That doesn't include the Common Language Runtime.

by judah 9y ago

algorithmsRcool 9y ago

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.

Kuraj 9y ago
12 megabytes doesn't sound too bad for the things you mentioned, especially if it's a constant cost.
svick 9y ago
> 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.

userbinator 9y ago

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.

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