Scott Hanselman

Experimental: Reducing the size of .NET Core applications with Mono's Linker

August 29, '17 Comments [22] Posted in DotNetCore
Sponsored By

The .NET team has built a linker to reduce the size of .NET Core applications. It is built on top of the excellent and battle-tested mono linker. The Xamarin tools also use this linker so it makes sense to try it out and perhaps use it everywhere!

"In trivial cases, the linker can reduce the size of applications by 50%. The size wins may be more favorable or more moderate for larger applications. The linker removes code in your application and dependent libraries that are not reached by any code paths. It is effectively an application-specific dead code analysis." - Using the .NET IL Linker

I recently updated a 15 year old .NET 1.1 application to cross-platform .NET Core 2.0 so I thought I'd try this experimental linker on it and see the results.

The linker is a tool one can use to only ship the minimal possible IL code and metadata that a set of programs might require to run as opposed to the full libraries. It is used by the various Xamarin products to extract only the bits of code that are needed to run an application on Android, iOS and other platforms.

I'll add this line to a nuget.config in my project's folder. Note that NuGet will inherit global settings and ADD this line.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="dotnet-core" value="https://dotnet.myget.org/F/dotnet-core/api/v3/index.json" />
</packageSources>
</configuration>

Then I'll add the IL Linker's NuGet package to my project with this command line command (or from Visual Studio):

dotnet add package ILLink.Tasks -v 0.1.4-preview-906439

The assemblies will automatically be "trimmed" when they are published (not built) so I'll build it twice, disabling it with a switch:

D:\github\TinyOS\OS Project>dotnet publish -c release -r win-x64 -o notlinked /p:LinkDuringPublish=false
Microsoft (R) Build Engine version 15.3 for .NET Core

TinyOSCore -> D:\github\TinyOS\OS Project\bin\Release\netcoreapp2.0\win-x64\TinyOSCore.dll
TinyOSCore -> D:\github\TinyOS\OS Project\notlinked\

D:\github\TinyOS\OS Project>dotnet publish -c release -r win-x64 -o linked
Microsoft (R) Build Engine version 15.3 for .NET Core

TinyOSCore -> D:\github\TinyOS\OS Project\bin\Release\netcoreapp2.0\win-x64\TinyOSCore.dll
TinyOSCore -> D:\github\TinyOS\OS Project\linked\

And here's the results:

image

You can also run it with  /p:ShowLinkerSizeComparison=true and get a nice table. I've trimmed the table as it's super long.

  TinyOSCore -> D:\github\TinyOS\OS Project\bin\Release\netcoreapp2.0\win-x64\TinyOSCore.dll
Before linking (B) After linking (B) Size decrease
----------- ----------- ----------- -----------
Total size of assemblies 48,025,824 16,740,056 65.14%
----------- ----------- ----------- -----------
TinyOSCore.dll 36,352 36,352 0.00%
Microsoft.Extensions.Configuration.dll 24,584 24,584 0.00%
Microsoft.Extensions.Configuration.Abstractions.dll 20,480 20,480 0.00%
Microsoft.Extensions.Configuration.Binder.dll 24,064 24,064 0.00%
Microsoft.Extensions.Configuration.FileExtensions.dll 22,528 22,528 0.00%
Microsoft.Extensions.Configuration.Json.dll 24,072 24,072 0.00%
Microsoft.Extensions.DependencyInjection.dll 46,600 46,600 0.00%
Microsoft.Extensions.DependencyInjection.Abstractions.dll 35,336 35,336 0.00%
Microsoft.Extensions.FileProviders.Abstractions.dll 17,920 17,920 0.00%
Microsoft.Extensions.FileProviders.Physical.dll 31,240 31,240 0.00%
Microsoft.Extensions.FileSystemGlobbing.dll 39,432 39,432 0.00%
Microsoft.Extensions.Options.dll 26,120 26,120 0.00%
Microsoft.Extensions.Options.ConfigurationExtensions.dll 16,904 16,904 0.00%
Microsoft.Extensions.Primitives.dll 33,800 33,800 0.00%
Newtonsoft.Json.dll 639,488 639,488 0.00%
Microsoft.CSharp.dll 1,092,096 392,192 64.09%
Microsoft.VisualBasic.dll 465,416 0 100.00%
Microsoft.Win32.Primitives.dll 18,968 4,608 75.71%
Microsoft.Win32.Registry.dll 85,008 0 100.00%
SOS.NETCore.dll 54,264 0 100.00%
System.AppContext.dll 14,336 2,560 82.14%
System.Buffers.dll 14,336 2,560 82.14%
System.Collections.Concurrent.dll 206,360 31,744 84.62%
System.Collections.Immutable.dll 2,378,264 0 100.00%
System.Collections.NonGeneric.dll 96,792 24,576 74.61%
System.Collections.Specialized.dll 88,608 15,360 82.67%
System.Collections.dll 326,664 52,224 84.01%

TinyOSCore -> D:\github\TinyOS\OS Project\bin\Release\netcoreapp2.0\win-x64\publish\

You can see in some places where there's no size decrease. That's because I'm using those assemblies completely. Some see a 100% decrease - they've been removed entirely - because I'm not using the Registry, for example. And some see a fractional decrease because I'm using some methods but not others.

You can check out the full instructions and try this yourself at https://github.com/dotnet/core/blob/master/samples/linker-instructions.md. Again, it's a work in progress.


Sponsor: Check out JetBrains Rider: a new cross-platform .NET IDE. Edit, refactor, test and debug ASP.NET, .NET Framework, .NET Core, Xamarin or Unity applications. Learn more and download a 30-day trial!

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb
Tuesday, 29 August 2017 20:05:15 UTC
This is brilliant. I can't wait to test this out
Tuesday, 29 August 2017 21:07:09 UTC
I see the benefit but, with space being so cheap, is there a specific use case for doing this today? Or is this more a benefit that we will all inherit via Visual Studio in the future?
Tuesday, 29 August 2017 22:04:53 UTC
@Jason, start thinking about stuff like Docker containers. In the microservices world, you could have 10, 20, 30 different .NET core images, one for each microservice or application. Prior to this, each one would have those complete sets of DLLs. Now imagine the network transfer time of repeatedly downloading those images from repo to client. Or memory when loading an assembly. Or cost of storage and/or data transfer in the cloud.
Richard Gavel
Wednesday, 30 August 2017 05:48:04 UTC
@Jason: for example, we work on industrial automation, where hard disks are generally as small as possible - think less than 10 GB, with Windows (LTSB) taking a big chunk of it. What remains is pretty valuable to us...
El Dorko
Wednesday, 30 August 2017 07:46:01 UTC
@Jason - Good points from other, I would just like to add two points:
1. Mobile apps (storage on mobile phones is limited and expensive)
2. Optimize because you can :)
Jarle Nygård
Wednesday, 30 August 2017 07:50:20 UTC
Why would this not be the default publishing mode for any project?
Manuel
Wednesday, 30 August 2017 08:14:24 UTC
How does this act with reflection code?
Mladen Mihajlovic
Wednesday, 30 August 2017 09:10:34 UTC
@Mladen look here https://github.com/dotnet/core/blob/master/samples/linker-instructions-advanced.md
Wednesday, 30 August 2017 11:59:16 UTC
>>> Why would this not be the default publishing mode for any project?

Probably because it's still a work in progress. Given some time, I'm willing to bet it will become part of the regular publishing process.
Wednesday, 30 August 2017 18:49:51 UTC
Example for creating a docker image with the self-contained program are here:
https://github.com/dotnet/dotnet-docker-samples/tree/master/dotnetapp-selfcontained

The reason this isn't the default, at least for docker images, is that having N different programs in N containers would also each have N copies of the necessary assemblies.

If you instead had a common base docker layer with the core assemblies (like .NET Core 2.0 does) then that single copy on disk is shared across all images.

SO... if you have a single program in a container and no additional containers then this will likely be a win for you (smaller individual container).

BUT... as you add more programs in containers that could share a base layer you're better off using the dotnet or aspnetcore base layer and just add your program on top of that (base layer will be pulled once and only the small program updates will need to be pulled per container).
Karg
Thursday, 31 August 2017 12:17:20 UTC
The assemblies will automatically be "trimmed" when they are published (not built) so I'll build it twice


You probably meant "so I'll publish it twice".
Thursday, 31 August 2017 20:21:53 UTC
That's pretty neat! Will test for sure.
Pablo
Friday, 01 September 2017 06:24:24 UTC
Brought back memories of static linking, actual .lib projects (not DLLs) and whole program optimization in the late 1980s; all of which existed in the 1970s.

Unfortunately, .net prevents creating a .Lib project where methods in the .lib are included in the application compiled against the .lib. Unlike a DLL which is a different file to be managed, stored, packaged, ...

How much extra work, such as code attributes, does it need to not remove the 100s of ASP.NET MVC controller methods which Visual Studio detects as unused?

Our larger systems have upwards of 1 code attribute line for every 20 lines of non-attribute based code. Ugly, and an anti-pattern mainly from EF.


Yuri
Saturday, 02 September 2017 22:42:21 UTC
Excellent information, thanks.
Tim
Monday, 04 September 2017 22:27:04 UTC
Is it just me or everyone seems is getting g "access denied" when clicking the "Newsletter" besides the About?


http://www.hanselman.com/newsletter/
Wednesday, 06 September 2017 02:21:19 UTC
It's very nice example to reduce size of application it will be very helpful for large applications. Thanks for sharing.
Wednesday, 06 September 2017 07:28:53 UTC
Thank you for sharing such a good and useful information here!
* dragon ball super | animeyt
Chalchiuhticue Naabah
Thursday, 07 September 2017 10:13:41 UTC
nice information thanks for free printable grid paper download the great post.
Monday, 11 September 2017 14:34:30 UTC
This sounds great, especially for micro services etc
Andy
Wednesday, 13 September 2017 14:28:27 UTC
Awesome and interesting article. Thanks for sharing unique knowledges!
guest survey
Guest
Wednesday, 13 September 2017 19:42:27 UTC
koimoi, 1st day box office collection
koimoi, box office collection, total collection, 1st day, collection
Wednesday, 13 September 2017 19:46:51 UTC
total collection koimoi hungama
box office collection koimoi hungama
Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.