3 ms·

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

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?

naikrovek 8y ago
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.
- matthewwarren 8y ago
  > 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
matthewwarren 8y ago
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.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?
chrisseaton 8y ago
AOT Java images are also around 4 MB. Maybe the GC in both takes up around 4 MB?
- coldacid 8y ago
  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.
  - chrisseaton 8y ago
    I thought most AOT tools did tree shaking, or whole-world analysis?
  - matthewwarren 8y ago
    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/#helloworld http://mattwarren.org/2018/06/07/CoreRT-.NET-Runtime-for-AOT...) includes the GC as well.
matthewwarren 8y ago
> 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 https://gitter.im/dotnet/corert?at=5b1af059178709146f21076f for some techniques to do this

naikrovek 8y ago

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.

matthewwarren 8y ago
> 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

matthewwarren 8y ago

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

chrisseaton 8y ago

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

coldacid 8y ago
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.
- chrisseaton 8y ago
  I thought most AOT tools did tree shaking, or whole-world analysis?
- matthewwarren 8y ago
  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/#helloworld http://mattwarren.org/2018/06/07/CoreRT-.NET-Runtime-for-AOT...) includes the GC as well.

matthewwarren 8y ago

> 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 https://gitter.im/dotnet/corert?at=5b1af059178709146f21076f for some techniques to do this