Native .so files are considerably larger in 5.0 than they were in 3.1

[eerhardt]

Steps to repro:

1. Using the latest SDK https://github.com/dotnet/installer#installers-and-binaries, create and publish a Hello World app:
   • dotnet new console
   • dotnet publish -r linux-x64 -c Release
2. Check the sizes of the output .so files. Using 5.0.0-preview.8.20361.2 of the runtime, I see:

Assembly	Size
libclrjit.so	3,323 KB
libcoreclr.so	11,532 KB
libmscordaccore.so	4,095 KB
libSystem.IO.Compression.Native.so	900 KB

3. Now use a 3.1 app and publish:

Assembly	Size
libclrjit.so	2,997 KB
libcoreclr.so	9,172 KB
libmscordaccore.so	3,400 KB
libSystem.IO.Compression.Native.so	771 KB

Why did these assemblies get so much bigger in 5.0? coreclr grew by about 25%.

cc @vitek-karas @janvorli

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[richlander]

I am looking at the same thing. PTAL https://gist.github.com/richlander/74e04d1d59169c28012797bb4e36d0af

Initial findings (assuming my script/methodology is good):

Regressions

• Linux 5.0 P7
  • Runtime-dependent increased to 216k from 96k (3.1)
  • Self-contained increased to 82MB from 78MB (3.1)
  • Self-contained multi-file linked increased to 41MB from 35MB

Wins

• Windows 5.0 P8
  • Runtime-dependent decreased to 158k from 180k (3.1)
  • Self-contained single-file decreased to 60MB from 69MB (3.1)
  • Self-contained single-file linked decreased to 20MB from 26MB
• Linux 5.0 P7
  • Self-contained single-file linked native-embed ready-to-run decreased to 29MB from 36MB

[eerhardt]

Note I am also seeing .a files in my publish directory which are also bloating the size. This is tracked by #3447.

[richlander]

I am seeing the same thing:

root@c596f6ef8464:/app1# dotnet --version
5.0.100-preview.7.20364.3
root@c596f6ef8464:/app1# find ./bin | grep .Native.a
./bin/Debug/net5.0/linux-x64/libSystem.Native.a
./bin/Debug/net5.0/linux-x64/libSystem.IO.Compression.Native.a
./bin/Debug/net5.0/linux-x64/libSystem.Net.Security.Native.a
root@c596f6ef8464:/app1# cd bin/Debug/net5.0/linux-x64/
root@c596f6ef8464:/app1/bin/Debug/net5.0/linux-x64# ls -l |grep Native.a
-rwxr--r-- 1 root root  3671090 Jun 26 07:47 libSystem.IO.Compression.Native.a
-rwxr--r-- 1 root root   427462 Jun 26 07:47 libSystem.Native.a
-rwxr--r-- 1 root root    36752 Jun 26 07:47 libSystem.Net.Security.Native.a
root@c596f6ef8464:/app1/bin/Debug/net5.0/linux-x64# ls -l |grep Native.so
-rwxr--r-- 1 root root   921512 Jun 26 07:47 libSystem.IO.Compression.Native.so
-rwxr--r-- 1 root root    95192 Jun 26 07:47 libSystem.Native.so
-rwxr--r-- 1 root root    18952 Jun 26 07:47 libSystem.Net.Security.Native.so

[janvorli]

I did some initial investigations doing local builds. Here are the findings:

• It is not caused by a different compiler version. Building .NET 5 with Clang 3.9 and 9 gets almost identical sizes of libcoreclr.so (difference < 10kB)
• Comparing file sizes from a build of the runtime repo in the early days (end of December) and the current state shows 430kB growth in libcoreclr.so size which is far below the observed difference from the 3.1 size.
• Comparing 3.1 size from the end of December and the build of the runtime repo in the early days, I can see about 2MB size increase in libcoreclr.so size.

So it seems that something in the coreclr -> runtime migration changes caused that jump. I am going to take a look at the compiler and linker options to see if I can spot something.

[janvorli]

Looking at current master branch vs 3.1 and dumping the sections of the libcoreclr.so, I've found that one section had a growth of 2.5MB. It is the .rodata (read only data) section.
The .text section (code) has grown only a tiny negligible bit - 160kB.
The other sections have grown a bit too, but each in terms of tens of kilobytes.

Compiler options are the same for 3.1 and 5, linker options differ a bit (5 has additional -Wl,-z,relro,-z,now), but adding these to the coreclr build didn't change the .rodata section. So it seems more like some real change that came in between the 3.1 and 5, maybe to the coreclr master branch even before the migration to the runtime repo.

[jkotas]

I see a lot of duplication in the .rodata section caused by duplication of SELECTANY data. For example, the SOFTWARE\\Policies\\Microsoft\\Windows\\Windows Error Reporting\\DebugApplications string is duplicated in libcoreclr.so 383 times. That's 60kB wasted right there and it is just one of the many SELECTANY variables we got. We had the same problem in 3.1, but it was slightly less severe - this string specific string is duplicated "only" 341 times in 3.1 libcoreclr.so. I believe what happened is that more header files includes got added here and there that made the problem much worse.

There are not that many SELECTANY uses and it is not the first time SELECTANY is causing us grief on non-Windows platforms. It is clearly non-portable construct. We should get rid of all SELECTANY uses (and also all constant data definitions in the header files - I see some waste from that too).

[jkotas]

also all constant data definitions in the header files

One example: shash_primes table is duplicated 22 times. That's 5.5kB wasted.