Hacker News Reader

Comment by mwcampbell | Hacker News Reader

If the compiler does tree-shaking, I wonder why it takes ~4 MB just to print a message on the console using the standard library. Is there any way to do a more fine-grained breakdown of where all that code is coming from?

View on HN

They are big leaves/fruit and there are only about 30(?) or so of them.

There is no easy way that I'm aware of. IIRC, early versions of this included the entire framework, so it's gotten a lot better.

> They are big leaves/fruit and there are only about 30(?) or so of them.

Ah, yeah that makes sense, I'd not thought about it like that.

> IIRC, early versions of this included the entire framework, so it's gotten a lot better

Yeah, they're definitely improving things over time

I wondered the same thing, it seems like 'System.Private.CoreLib.dll' is all or nothing, unless of course you write your own version such like 'Test.CoreLib' (https://github.com/dotnet/corert/tree/master/src/Test.CoreLi...)

I don't know if it's technically impossible or just hard to have 'tree-shaking' being done on it, so that you only get the functions/dependencies that are actually called?

> Is there any way to do a more fine-grained breakdown of where all that code is coming from?

See https://gitter.im/dotnet/corert?at=5b1af059178709146f21076f for some techniques to do this

AOT Java images are also around 4 MB. Maybe the GC in both takes up around 4 MB?

The GC code isn't _that_ big. It's because AOT compilers tend to turn each assembly/package into a single code object for linking, instead of a library of objects that can be filtered to just the code needed.

I thought most AOT tools did tree shaking, or whole-world analysis?

I just double checked and you're right, the GC code is pretty small. The 0.49 MB run-time `Test.CoreLib` (http://mattwarren.org/2018/06/07/CoreRT-.NET-Runtime-for-AOT...) includes the GC as well.

Reply on news.ycombinator.com