.NET: SingleView app size

[rolfbjarne]

App sizes are currently significantly bigger with .NET 6 with a very simple hello world app.

Test case

• Checkout xamarin-macios
• Execute:

cd tests/dotnet
make compare

This will build a very simple hello world app for both .NET 6 and the old-style Xamarin.iOS and generate a report in markdown format. This can be pasted into the issue (e.g. for each preview) so the progress can be tracked.

Known Issues

• The (dynamic) registrar isn't removed when enabling all the optimizations
  • The dynamic registrar requires a larger subset of System.Reflection API (see below)
• The .NET 6 version does not strip the native executable.
• The mono-cil-strip tool is not run on the final assemblies (it's not available without the mono SDK installed)
  • All assemblies still have their IL even when it's not required (FullAOT by default for device builds)
  • Tracked, among other tools, in Packaging & redistribution of mdoc.exe & mono-symbolicate in a .NET 6 world? dotnet/runtime#35852 @marek-safar recently mentioned it was being looked at for Blazor (there might be another issue I missed)

Historical

App sizes

Xamarin.iOS

du -hs size-comparison/MySingleView/oldnet/bin/iPhone/Release/MySingleView.app
4.4M size-comparison/MySingleView/oldnet/bin/iPhone/Release/MySingleView.app

.NET 6

du -hs size-comparison/MySingleView/dotnet/bin/iPhone/Release/net6.0-ios/ios-arm64/*.app
27M size-comparison/MySingleView/dotnet/bin/iPhone/Release/net6.0-ios/ios-arm64/MySingleView.app

Assembly sizes

Xamarin.iOS

ls -lahS size-comparison/MySingleView/oldnet/bin/iPhone/Release/MySingleView.app/.dll size-comparison/MySingleView/oldnet/bin/iPhone/Release/MySingleView.app/.exe
-rw-r--r-- 1 rolf wheel 397K Dec 9 19:04 size-comparison/MySingleView/oldnet/bin/iPhone/Release/MySingleView.app/mscorlib.dll
-rw-r--r-- 1 rolf wheel 54K Dec 9 19:04 size-comparison/MySingleView/oldnet/bin/iPhone/Release/MySingleView.app/Xamarin.iOS.dll
-rw-r--r-- 1 rolf wheel 4.5K Dec 9 19:04 size-comparison/MySingleView/oldnet/bin/iPhone/Release/MySingleView.app/MySingleView.exe
-rw-r--r-- 1 rolf wheel 4.5K Dec 9 19:05 size-comparison/MySingleView/oldnet/bin/iPhone/Release/MySingleView.app/System.dll

.NET 6

ls -lahS size-comparison/MySingleView/dotnet/bin/iPhone/Release/net6.0-ios/ios-arm64/.app/.dll
-rw-r--r-- 1 rolf wheel 1.3M Dec 9 19:05 size-comparison/MySingleView/dotnet/bin/iPhone/Release/net6.0-ios/ios-arm64/MySingleView.app/System.Private.CoreLib.dll
-rw-r--r-- 1 rolf wheel 161K Dec 9 19:05 size-comparison/MySingleView/dotnet/bin/iPhone/Release/net6.0-ios/ios-arm64/MySingleView.app/Xamarin.iOS.dll
-rw-r--r-- 1 rolf wheel 17K Dec 9 19:05 size-comparison/MySingleView/dotnet/bin/iPhone/Release/net6.0-ios/ios-arm64/MySingleView.app/System.Runtime.dll
-rw-r--r-- 1 rolf wheel 16K Dec 9 19:05 size-comparison/MySingleView/dotnet/bin/iPhone/Release/net6.0-ios/ios-arm64/MySingleView.app/System.Runtime.Serialization.Formatters.dll
-rw-r--r-- 1 rolf wheel 5.0K Dec 9 19:05 size-comparison/MySingleView/dotnet/bin/iPhone/Release/net6.0-ios/ios-arm64/MySingleView.app/MySingleView.dll

---

There are multiple issues here:

• The .NET 6 version has unnecessary dylibs (because it's linking libraries statically). fix
• The .NET 6 version does not strip the native executable.
• The .NET 6 version's assemblies are much bigger (the linker doesn't remove as much): 1,5 MB vs 460 KB.

Additionally the .NET 6 version takes twice as long to compile (22s vs 11s on my machine), but that's a different issue (filed as #10251).

[spouliot]

Shameless plug but you might want to use https://github.com/spouliot/dotnet-tools/tree/master/app-compare to compare the size of the current/dotnet apps

[spouliot]

Additionally the .NET 6 version takes twice as long to compile (22s vs 11s on my machine), but that's a different issue.

Considering most of the device build time comes from the AOT compiler (at least in current form) then a 2x build time increase is not so bad as there's more than 3x more managed code (1,5 MB vs 460 KB) to AOT. IOW we can consider this the "same issue", unless the time increase comes from elsewhere.

[marek-safar]

It looks like you don't have some of the feature switched enabled, see https://github.com/dotnet/runtime/blob/master/docs/workflow/trimming/feature-switches.md. I'm not saying that's all that needs to be done but it's a good start ;-)

[spouliot]

Application Comparer

• A oldnet/bin/iPhone/Release/MySingleView.app
• B dotnet/bin/iPhone/Release/net6.0-ios/ios-arm64/MySingleView.app

Directories / Files	A	B	diff	%
.//_CodeSignature
.//
embedded.mobileprovision	12,218	12,218	0	0.0%
Info.plist	1,055	1,055	0	0.0%
libmonosgen-2.0.dylib	0	3,177,312	3,177,312	-
libSystem.IO.Compression.Native.dylib	0	827,104	827,104	-
libSystem.Native.dylib	0	123,040	123,040	-
libSystem.Net.Security.Native.dylib	0	72,016	72,016	-
libSystem.Security.Cryptography.Native.Apple.dylib	0	80,656	80,656	-
libxamarin-debug.dylib	0	623,856	623,856	-
libxamarin.dylib	0	425,408	425,408	-
mscorlib.aotdata.arm64	296,872	0	-296,872	-100.0%
mscorlib.dll	406,528	0	-406,528	-100.0%
MySingleView	3,748,192	18,281,760	14,533,568	387.7%
MySingleView.aotdata.arm64	816	1,136	320	39.2%
MySingleView.dll	0	5,120	5,120	-
MySingleView.exe	4,608	0	-4,608	-100.0%
MySingleView.pdb	0	9,720	9,720	-
PkgInfo	8	8	0	0.0%
System.aotdata.arm64	752	0	-752	-100.0%
System.dll	4,608	0	-4,608	-100.0%
System.Private.CoreLib.aotdata.arm64	0	3,082,504	3,082,504	-
System.Private.CoreLib.dll	0	1,391,616	1,391,616	-
System.Runtime.aotdata.arm64	0	504	504	-
System.Runtime.dll	0	17,408	17,408	-
System.Runtime.Serialization.Formatters.aotdata.arm64	0	1,144	1,144	-
System.Runtime.Serialization.Formatters.dll	0	15,872	15,872	-
Xamarin.iOS.aotdata.arm64	35,048	319,112	284,064	810.5%
Xamarin.iOS.dll	55,296	163,840	108,544	196.3%
Statistics
Native subtotal	3,748,192	18,281,760	14,533,568	387.7%
Executable	3,748,192	18,281,760	14,533,568	387.7%
AOT data *.aotdata	0	0	0	-
Managed *.dll/exe	471,040	1,593,856	1,122,816	238.4%
TOTAL	4,571,262	28,640,968	24,069,706	526.5%

[spouliot]

other issues

• debugging symbol files, like MySingleView.pdb, should not be copied to release .app
• otool -L MySingleView does not show libicu* nor is there any data files. AFAIK those are required for globalization of net5+ apps (and the existing oldnet app has globalization support)

update: both issues are fixed with P4

[marek-safar]

@spouliot could you share the binaries?

[spouliot]

@marek-safar yes but likely not today. My main internet connection is down :( and I'm waiting for a new modem to be delivered. Trying to limit myself to low bandwidth (cellular) tasks.

[rolfbjarne]

It looks like you don't have some of the feature switched enabled, see https://github.com/dotnet/runtime/blob/master/docs/workflow/trimming/feature-switches.md. I'm not saying that's all that needs to be done but it's a good start ;-)

#10250 - that shaves off a good chunk.

[rolfbjarne]

@marek-safar

@spouliot could you share the binaries?

dotnet.zip
oldnet.zip

That's after #10250, so the runtime switches have been toggled for these apps.

[rolfbjarne]

Additionally the .NET 6 version takes twice as long to compile (22s vs 11s on my machine), but that's a different issue.

Considering most of the device build time comes from the AOT compiler (at least in current form) then a 2x build time increase is not so bad as there's more than 3x more managed code (1,5 MB vs 460 KB) to AOT. IOW we can consider this the "same issue", unless the time increase comes from elsewhere.

I filed #10251 for this: just executing the .NET 6 linker takes longer than linking + AOT compilation + native compilation used to.

[spouliot]

This update was done with today's dotnet 6.0.100-preview.2.21158.2 build and xamarin-macios main 91ce22c. Not quite the final, to be released, P2 bits but close.

Most of the previous comments (e.g. extra files, no ICU in numbers) still applies.

Noticeable/visible changes are:

• removal of System.Runtime.dll
• removal of System.Runtime.Serialization.Formatters.dll
• reduction of System.Private.CoreLib.dll

It's a great improvement, over the original numbers, but there's still work to be done compared to the current SDK size.

Application Comparer

• A /Users/poupou/git/master/xamarin-macios/tests/dotnet/size-comparison/MySingleView/oldnet/bin/iPhone/Release/MySingleView.app
• B /Users/poupou/git/master/xamarin-macios/tests/dotnet/size-comparison/MySingleView/dotnet/bin/iPhone/Release/net6.0-ios/ios-arm64/MySingleView.app

Directories / Files	A	B	diff	%
.//_CodeSignature
.//
embedded.mobileprovision	14,271	14,271	0	0.0%
Info.plist	1,058	1,058	0	0.0%
libmonosgen-2.0.dylib	0	3,503,920	3,503,920	-
libSystem.IO.Compression.Native.dylib	0	827,248	827,248	-
libSystem.Native.dylib	0	123,792	123,792	-
libSystem.Net.Security.Native.dylib	0	72,016	72,016	-
libSystem.Security.Cryptography.Native.Apple.dylib	0	80,656	80,656	-
libxamarin-debug.dylib	0	625,472	625,472	-
libxamarin-dotnet-debug.dylib	0	625,600	625,600	-
libxamarin-dotnet.dylib	0	425,984	425,984	-
libxamarin.dylib	0	425,856	425,856	-
mscorlib.aotdata.arm64	296,808	0	-296,808	-100.0%
mscorlib.dll	406,528	0	-406,528	-100.0%
MySingleView	3,748,304	10,213,120	6,464,816	172.5%
MySingleView.aotdata.arm64	816	792	-24	-2.9%
MySingleView.dll	0	4,608	4,608	-
MySingleView.exe	4,608	0	-4,608	-100.0%
MySingleView.pdb	0	10,280	10,280	-
PkgInfo	8	8	0	0.0%
System.aotdata.arm64	752	0	-752	-100.0%
System.dll	4,608	0	-4,608	-100.0%
System.Private.CoreLib.aotdata.arm64	0	623,496	623,496	-
System.Private.CoreLib.dll	0	685,056	685,056	-
Xamarin.iOS.aotdata.arm64	34,856	78,784	43,928	126.0%
Xamarin.iOS.dll	55,296	157,696	102,400	185.2%
Statistics
Native subtotal	3,748,304	10,213,120	6,464,816	172.5%
Executable	3,748,304	10,213,120	6,464,816	172.5%
AOT data *.aotdata	0	0	0	-
Managed *.dll/exe	471,040	847,360	376,320	79.9%
TOTAL	4,573,174	18,507,576	13,934,402	304.7%

[eerhardt]

@spouliot @rolfbjarne - do we know why Xamarin.iOS.dll is 185% larger in .NET 6?

That could contribute a lot to why .NET 6's CoreLib is bigger than mono's mscorlib. More code in higher level assemblies means the possibility of more code being rooted lower in corelib.

[spouliot]

do we know why Xamarin.iOS.dll is 185% larger in .NET 6?

No, at least not yet. I wanted numbers to go along P2 even if we did not have time to look at the results right away - they will have historical value ;-)

Quick guess some of our optimizations were not yet ported/enabled (last time I checked).

That could contribute a lot to why .NET 6's CoreLib is bigger than mono's mscorlib.

That definitively plays its part. Still even if Xamarin.iOS.dll is huge (lots of bindings) there's not a lot of variety in the API being used. I'll dig up more useful data asap

[spouliot]

I took a quick look at the assembly last night and what I've seen is largely (still) disabled optimizations.

• The dynamic registrar is not removed (missing optimization) so there's more usage (than normal) of System.Reflection API.
• Several build-time only attributes are not removed (missing optimization) -> mostly metadata
• UIThread checks are not removed (missing optimization) -> an extra call for some methods

Only one (dynamic registrar) would have a significant impact on what's required inside System.Private.CoreLib.dll but the recursive effect might be larger.

Update

I missed the most obvious - since I can see the IL of the dotnet version it means the mono-cil-strip was not run against the assembly (which is normally done as Full AOT is used). That's likely the biggest contributor to the extra size of the assembly.

[spouliot]

Numbers from 6.0.1xx-preview3 using 6.0.100-preview.3.21202.5

Notes:

• ICU is not enable (no data file included) but likely part of the binary (executable) size increase.

Application Comparer

• A /Users/poupou/git/net6/p3/xamarin-macios/tests/dotnet/size-comparison/MySingleView/oldnet/bin/iPhone/Release/MySingleView.app
• B /Users/poupou/git/net6/p3/xamarin-macios/tests/dotnet/size-comparison/MySingleView/dotnet/bin/iPhone/Release/net6.0-ios/ios-arm64/MySingleView.app

Directories / Files	A	B	diff	%
.//_CodeSignature
.//
embedded.mobileprovision	12,391	12,391	0	0.0%
Info.plist	1,063	1,063	0	0.0%
libmonosgen-2.0.dylib	0	6,245,360	6,245,360	-
libSystem.IO.Compression.Native.dylib	0	827,248	827,248	-
libSystem.Native.dylib	0	124,480	124,480	-
libSystem.Net.Security.Native.dylib	0	72,016	72,016	-
libSystem.Security.Cryptography.Native.Apple.dylib	0	80,992	80,992	-
libxamarin-dotnet-debug.dylib	0	627,008	627,008	-
libxamarin-dotnet.dylib	0	428,032	428,032	-
mscorlib.aotdata.arm64	297,304	0	-297,304	-100.0%
mscorlib.dll	407,552	0	-407,552	-100.0%
MySingleView	3,749,104	13,298,528	9,549,424	254.7%
MySingleView.aotdata.arm64	816	792	-24	-2.9%
MySingleView.dll	0	4,608	4,608	-
MySingleView.exe	4,608	0	-4,608	-100.0%
MySingleView.pdb	0	10,296	10,296	-
PkgInfo	8	8	0	0.0%
System.aotdata.arm64	752	0	-752	-100.0%
System.dll	4,608	0	-4,608	-100.0%
System.Private.CoreLib.aotdata.arm64	0	653,536	653,536	-
System.Private.CoreLib.dll	0	721,408	721,408	-
System.Runtime.CompilerServices.Unsafe.aotdata.arm64	0	7,232	7,232	-
System.Runtime.CompilerServices.Unsafe.dll	0	6,656	6,656	-
Xamarin.iOS.aotdata.arm64	35,720	80,912	45,192	126.5%
Xamarin.iOS.dll	56,320	159,744	103,424	183.6%
Statistics
Native subtotal	3,749,104	13,298,528	9,549,424	254.7%
Executable	3,749,104	13,298,528	9,549,424	254.7%
AOT data *.aotdata	0	0	0	-
Managed *.dll/exe	473,088	892,416	419,328	88.6%
TOTAL	4,575,507	23,370,285	18,794,778	410.8%

[spouliot]

Results with the release/6.0.1xx-preview4 branch

Major changes from P3 is that it includes the ICU data file icudt.dat for globalization while removing the .dylib and .pdb.

Application Comparer

Directories / Files	Legacy	6.0.1xx-preview4	diff	%
.//_CodeSignature
.//
embedded.mobileprovision	12,391	12,391	0	0.0%
icudt.dat	0	1,713,152	1,713,152	-
Info.plist	1,076	1,076	0	0.0%
mscorlib.aotdata.arm64	297,312	0	-297,312	-100.0%
mscorlib.dll	407,552	0	-407,552	-100.0%
MySingleView	3,749,280	13,989,808	10,240,528	273.1%
MySingleView.aotdata.arm64	816	792	-24	-2.9%
MySingleView.dll	0	4,608	4,608	-
MySingleView.exe	4,608	0	-4,608	-100.0%
PkgInfo	8	8	0	0.0%
System.aotdata.arm64	752	0	-752	-100.0%
System.dll	4,608	0	-4,608	-100.0%
System.Private.CoreLib.aotdata.arm64	0	718,504	718,504	-
System.Private.CoreLib.dll	0	802,304	802,304	-
System.Runtime.aotdata.arm64	0	504	504	-
System.Runtime.dll	0	5,120	5,120	-
Xamarin.iOS.aotdata.arm64	35,720	80,272	44,552	124.7%
Xamarin.iOS.dll	56,320	157,696	101,376	180.0%
Statistics
Native subtotal	3,749,280	13,989,808	10,240,528	273.1%
Executable	3,749,280	13,989,808	10,240,528	273.1%
AOT data *.aotdata	0	0	0	-
Managed *.dll/exe	473,088	969,728	496,640	105.0%
TOTAL	4,575,704	17,491,860	12,916,156	282.3%

[tipa]

I was excited to migrate my legacy Xamarin apps to .NET 6, but when I looked at the app sizes, I was a bit shocked.
One app that previously had an install size of 20MB now sits at 60MB, another app that previously had an install size of 60MB is now at 111MB. I thought I was doing something wrong with my .csproj settings and was about to file a new issue before I found this one.
Are these app size increases expected behaviour? Can you give any estimate when the app sizes will come down again to where they have been before with legacy Xamarin? Not feeling comfortable publishing an app update that increases the install size by 200%

[spouliot]

One app that previously had an install size of 20MB now sits at 60MB

@tipa that's above what I would have expected. In theory the percentage increase should be larger for small apps (hence why the measurements were done on an empty template app) because a lot of the "cost" is the runtime / corlib sizes. Anything that's more than twice the size (the templates results) sounds suspicious to me.

You might want to run appcompare on your legacy / net6 apps and share those reports. That might hint someone about what/where the problem is...

[tipa]

@spouliot Unfortunately the app compare command doesn't seem to work, I get this error when executing it in the terminal: zsh: command not found: appcompare

However, after inspecting the .ipa files and comparing legacy & .NET6 binaries, I made some observations:

• I replaced the AppCenter NuGets with Sentry, as AppCenter still does not have a working version for MAUI/.NET6. As it appears, the Sentry package is much larger than the AppCenter bindings
• .NET6 includes new packages by default, like System.Text.Json. The .dll is still in the .ipa (consuming over 550KB!), even though it is not used my app. System.Text.Json is referenced and used in a shared project that my app uses, but the class containing the usage is not used in my app and I would have expected this to be linked away.
• When inspecting the Frameworks folder in the app, it appears that for .NET6, the "Headers", "Modules" and "PrivateHeaders" folders are still in the final app package, while they are not present in the legacy Xamarin app package. I am using the Google Ads bindings for iOS and this causes a few Firebase & Google frameworks to be included in the app. While they are all only a few KBs, I expect them to add up to a few MBs. The Protobuf framework contains a few big header files as well, e.g. the GPBDictionary.h (192KB) and the GPBArray.h (60KB). Is this something that could be improved or are those header files mandatory in .NET6 apps?

What are the correct build & linker settings for .NET6 apps? I used MtouchLink=Full in the past. Should I now use _LinkMode=Full or TrimMode=link or something completely different?

[rolfbjarne]

@tipa

Unfortunately the app compare command doesn't seem to work

https://github.com/spouliot/appcompare#how-to-install

• Is this something that could be improved or are those header files mandatory in .NET6 apps?

This is probably something that can be improved, these header files are not mandatory in .NET apps.

An issue with a test project would help us look at this.

What are the correct build & linker settings for .NET6 apps? I used MtouchLink=Full in the past. Should I now use _LinkMode=Full or TrimMode=link or something completely different?

MtouchLink=Full is still supported and should do what it did in the past (link every assembly).

The easiest way to check if an assembly was linked is probably to check the size or md5 checksum of the assembly in the app bundle vs the one produced by the C# compiler earlier in the build.

Unfortunately, the next step, figuring out why a particular assembly isn't linked away, is a rather involved process:

1. Figure out which assemblies reference the assembly in question.
2. Go through them all, and see what they're using from the assembly in question.

[tipa]

https://github.com/spouliot/appcompare#how-to-install

This is probably something that can be improved, these header files are not mandatory in .NET apps.

An issue with a test project would help us look at this.

Small test project with reference to AdMob NuGet: test.zip

The easiest way to check if an assembly was linked is probably to check the size or md5 checksum of the assembly in the app bundle vs the one produced by the C# compiler earlier in the build

I commented out the (unused) class that referenced System.Text.Json and did another release build. The .dll was then removed completely.
Here's another small project to reproduce this problem. Note the unused class "Wormhole.cs" in the shared project: test 2.zip

It appears that shared projects aren't handled correctly by the linked?

[spouliot]

https://github.com/spouliot/appcompare#how-to-install

That's weird. Have you tried from a new terminal window ? I don't recall if dotnet tool has a first-time initialization.

Alternatively you could clone the repo and built the tool.

I commented out the (unused) class that referenced System.Text.Json and did another release build. The .dll was then removed completely.

Somehow, something had a reference to that type.

It could be your app - but then it would fail to build when commented.

It could be the linker that smartly detects JSON related types and decide to mark them since they are generally (if) used using reflection.

[tipa]

Have you tried from a new terminal window ?

Yes and I have also restarted macOS completely. I am using a Mac mini from 2020 if that is of relevance.

Somehow, something had a reference to that type.

I included a repo project in my comment above. When I call dotnet publish -c Release on it, the resulting .ipa contains many .dlls (System.Text.Json and more) that aren't used/called anywhere in the app.
It could be a problem with how the shared project is handled because it is linked away correctly if I include that unused class in the main project.
If this is not the scope of the xamarin-macios project can also submit this as an issue in a different Github repository.

[tipa]

Should I create separate issues for those problems? If so, in which repositories?
My 60 MB app almost doubled in it's install size, despite removing multiple dependencies (AppCenter, Microcharts, ...). Guess I will have to stick with legacy Xamarin on iOS for longer now, that increase in app size is too large...

I built the app compare tool myself but I can't get it to spit out any useful report. It doesn't seem to detect/process any of the files under the "App B" folder:

[spouliot]

@tipa speaking only of appcompare [1] that should not happen unless there's no match between the directories. Can you gist the output (it's built into the tool) ?

You can file appcompare issues / ideas / enhancements in my [repo](https://github.com/spouliot/appcompare](https://github.com/spouliot/appcompare#how-to-install)

[1] I'll let someone from Microsoft to answers the other issues, including where best to file them :)

[rolfbjarne]

Should I create separate issues for those problems? If so, in which repositories?

Yes, please file separate issues (in this repo, we'll move elsewhere if need be), that makes it much easier to handle them and not get confused (it's always easier to merge issues than it is to split an issue after everyone on the issue has become thoroughly confused).

[tipa]

I filed those issues here:
#15723
#15724
spouliot/appcompare#2

[rolfbjarne]

Update results:

Short answer: we're 6,8mb bigger (~148%) in .NET 8 than .NET 7 vs legacy Xamarin. NativeAOT makes it a little bit better, only 2,6mb bigger (57%). Comparing .NET 7 vs .NET 8 yields that the .NET 8 is 2,4mb bigger (27%).

.NET 7

Commit: a7e96e5

https://gist.github.com/rolfbjarne/0591a45002e40e4086f9d3132233f8ed

.NET 8

Commit: bf77022

https://gist.github.com/rolfbjarne/f01885cc66050f7ddb72f4fdec9d21b5

.NET 8 with NativeAOT

Commit: bf77022

https://gist.github.com/rolfbjarne/ffd61461a4565b75d7c231331e3d170b

.NET 7 vs .NET 8

https://gist.github.com/rolfbjarne/5d809f1fcc37852c922c47c54b8c79c8

[filipnavara]

Note that with NativeAOT we can use <IlcGenerateMstatFile>true</IlcGenerateMstatFile> and <IlcGenerateDgmlFile>true</IlcGenerateDgmlFile> to generate logs about the individual method size usage and dependencies. This can be analyzed with the SizoscopeX tool to pin-point specific parts of code that contribute to the overall size.

[psulek]

Note that with NativeAOT we can use <IlcGenerateMstatFile>true</IlcGenerateMstatFile> and <IlcGenerateDgmlFile>true</IlcGenerateDgmlFile> to generate logs about the individual method size usage and dependencies. This can be analyzed with the SizoscopeX tool to pin-point specific parts of code that contribute to the overall size.

You can also mention that this tool SizoscopeX is a fork of brillant mind MichalStrehovsky and his tool sizoscope

[rolfbjarne]

Updated results:

We're 2,2mb smaller (-19,6%) in .NET 9 vs .NET 8. The size decrease almost exactly matches the size increase from .NET 7 to .NET 8, so we're effectively back to where we were in .NET 7 size-wise.

[spouliot]

Is icudt.dat not needed anymore ? or was the net9 test app just build as invariant (which would be comparing apples to oranges since it could have been done in earlier, even pre-net60, releases) ?

[filipnavara]

The hybrid globalization option is default in
.NET 9 and it doesn’t need ICU anymore.

[spouliot]

Thanks, found it @ https://github.com/dotnet/runtime/blob/main/docs/design/features/globalization-hybrid-mode.md#apple-platforms