-
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
[mono][perf] iOS and WASM disk size regressions on 06 Dec 2022 #79285
Comments
Do we know where exactly the increase comes from? |
wasm report is here dotnet/perf-autofiling-issues#10461 at first glance it looks like the growth is primarily in System.Private.CoreLib and retained native code. |
How does one determine what native code is being retained that wasn't before, and why it's being retained? |
Tagging subscribers to 'size-reduction': @eerhardt, @SamMonoRT, @marek-safar Issue DetailsDescriptionChange in Enum values #78580 produced disk size regression in Mono iOS and WASM. Binary disk size (SOD) for Mono iOS sample has increased by 9.86%. Mono iOS details
Mono Blazorwasm details
cc @SamMonoRT @lewing @radekdoulik ConfigurationOS: iOS/OSX
|
I don't think that we can analyze a dependency graph. I suggest to compare native symbols before and after the change. Moreover, we can check ILLinker logs for any trimming/linking actions made before and after the change. Generics |
@jkotas, FYI |
@stephentoub, afaik currently there is no easy way to do this with Mono. We usually go through the changes and compare outputs as @kotlarmilos suggested. Regarding this, I have opened #73159 as a .NET 8 idea which would help us answer such questions and improve the overall experience for detecting these kind of issues. This being said, maybe we could utilize NativeAOT compiler's ILScanner mode, which we could run before and after a change in libraries' code, to dump the dependency graphs and track down what are all the new dependencies introduced by the change. |
Maybe https://github.com/google/bloaty might help here? Not sure if it can be used on iOS, but I believe I've heard of people using it for WASM before. |
I agree @eerhardt, I have used it along with a custom script to try to compare two separate binaries explained here: |
System.Private.CoreLib.dll IL size grew 30kB (1015808 to 1047552). System.Private.CoreLib.aotdata grew 184kB (930368 to 1118880). It means that there is disproportionally large growth in AOT size. System.Console.dll IL size have not changed and there are no changes in System.Console in this PR. System.Console.aotdata grew 75kB, that is more than doubled in size (63344 to 138632). This suggests that that the bulk of the regression is in generic expansion or inlining of something that is used by System.Console. My guess is that the bulk of the regression was triggered by https://github.com/dotnet/runtime/pull/78580/files#diff-b731ce4281dee295e9c8ad712cc211b7c8a0f9afee1a79e2a6bf248192fcd657R309-R320 . The AOT compiler may be expanding the enum path for every T and not just for enums. |
Seeing an 8% regression (for Hello World) in NativeAOT as well: #79437. |
Part of the increase seems to be caused by code like this:
Mono currently doesn't treat GetEnumUnderlyingType as an intrinsics. Even if that is implemented, it's not going to be smart enough to realize that 'underlyingType' points to typeof(int) at the if () location, so it can't optimize out the if () statements, forcing it to generate all the TryFormatPrimitiveDefault instances. |
Follow-up research on size improvements in Mono AOT compiler -- it seems that inflated instances in addition to gsharedvt created the regression with changes in Enum values. Bloaty symbols diff before and after the change - https://gist.github.com/kotlarmilos/a5c7c0b3372f0e019a9e2016ce7805e5 It seems that single @vargaz Is it something that we might consider as an option if a speed isn't affected much, or is it not an option? Bundles are attached for further comparison. |
This approach seems to involve special handling for Enum, which may not be the best solution overall. Since this doesn't appear to be a reasonable fix / high effort, I will close the issue. |
Description
Change in Enum values #78580 produced disk size regression in Mono iOS sample app and in Mono Blazorwasm.
Binary disk size (SOD) for Mono iOS sample has increased by 9.86%.
Framework disk size (SOD) for Mono AOT Blazorwasm sample has increased by 9.48%.
Details - Mono iOS sample app
Details - Mono WASM
Details - Mono AOT WASM
cc @SamMonoRT @lewing @radekdoulik
Configuration
iOS
OS: iOS/OSX
Architecture: arm64
.NET version: 7.0.100-rc.1.22431.12
WASM
OS: Ubuntu 18.04
Architecture: x64
.NET version: 7.0.100-rc.1.22431.12
The text was updated successfully, but these errors were encountered: