Experimental: Reducing the size of .NET Core applications with Mono's Linker
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:
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.
About Newsletter
Jeremy Sinclair
1. Mobile apps (storage on mobile phones is limited and expensive)
2. Optimize because you can :)
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.
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).
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".
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.
Comments are closed.