-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
libSystem.IO.Compression.Native size increased 15% #39598
Comments
The other native binaries from libraries regressed in similar fashion:
That's 207KB / 21% regression. |
Tagging subscribers to this area: @safern, @ViktorHofer |
@ViktorHofer @jkoritzinsky did anything relevant change in how we build these, since 3.1? |
@vitek-karas is it possible to crack the so's with some tool (similar to dumpbin on Windows) to get an idea where the size increase was? Of course it might be across the board, eg., different compilation flags. |
OK now I see the linked issue and I'm confused. @jkotas is it the case that @janvorli 's fix fixed the other 3, but not (for some reason) compression? And @vitek-karas's numbers happened to be without that fix? |
@janvorli fix affected libcoreclr.so and libclrjit.so only. It did not touch the libraries native shims. You should be able to still see the regression in latest nightly builds.
|
Stats from macOS (ignoring the
|
Not that I'm aware of. cc @jkoritzinsky @janvorli |
Not to my knowledge. |
This change might be related: |
Hmm, so the #685 is not related. The size before and after that change is the same. |
I've found that the reason for the growth here is the compiler. Compiling native shared libraries with clang 3.9 gets the same size as in .NET Core 3.1.
My guess is that clang 9 that we use to build .NET 5.0 unrolls loops in a more aggressive manner. |
I think we should measure the Brotli performance with and without the loop unrolling, and disable the loop unrolling optimizations if they do not make material difference. I have noticed that clang loop unrolling optimizations are very code-bloating and I have doubts about their effectiveness. We may want to disable them for coreclr as well. I suspect they are one of the contributors for why coreclr binaries are so much bigger on Linux. |
@janvorli would u be able to take a lead on this one ? |
I've measured performance with and without loop unrolling using the Brotli benchmarks. The impact of not unrolling was significant, between 6..9% for half of the benchmarks in the suite. All the results can be seen in the following gist: |
I've also looked at the other native shared libraries produced by the libraries build. Interestingly a significant part of the regression is caused by symbols. In 3.1, we were stripping all unneeded symbols, in 5.0, after unification of the stripping for all the three formerly separated repos, we are stripping only debugging symbols. |
Will be fixed by #41039. |
Yes, it is fixed, I have not realized I have not put the issue closing tag on the PR fixing it. |
Context: #39281
This is 15% increase even though we have not added any new compression algorithms.
Is this increase expected?
The text was updated successfully, but these errors were encountered: