-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Consider using .SizeOpt.cs in System.Linq built for Browser/Xamarin/AOT #45399
Comments
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. |
Tagging subscribers to this area: @eiriktsarpalis, @jeffhandley Issue DetailsWe previously added the *.SizeOpt.cs set of implementations for System.Linq.dll in order to cull out some generics-heavy optimizations that were adding significant overhead (often megabytes of asm in an app) to AOT compilations using LINQ. However, it also adds non-trivial IL size, e.g. a .dll built with the SpeedOpt files is currently ~128K whereas one built with the SizeOpt files is currently ~102K. For target frameworks where size is at a premium, we should consider using these .SizeOpt variants instead. For AOT builds, we should also look to use these SizeOpt variants. And if we're not going to use them in either, we should delete them and clean up the cruft. (We also should revisit a few specific optimizations, in particular the ToArray implementation that uses a complicated and large "LargeArrayBuilder", which is likely not worth its weight.) cc: @marek-safar, @eerhardt
|
We previously added the *.SizeOpt.cs set of implementations for System.Linq.dll in order to cull out some generics-heavy optimizations that were adding significant overhead (often megabytes of asm in an app) to AOT compilations using LINQ. However, it also adds non-trivial IL size, e.g. a .dll built with the SpeedOpt files is currently ~128K whereas one built with the SizeOpt files is currently ~102K (both sizes are untrimmed).
For target frameworks where size is at a premium, we should consider using these .SizeOpt variants instead.
For AOT builds, we should also look to use these SizeOpt variants.
And if we're not going to use them in either, we should delete them and clean up the cruft. (We also should revisit a few specific optimizations, in particular the ToArray implementation that uses a complicated and large "LargeArrayBuilder", which is likely not worth its weight.)
cc: @marek-safar, @eerhardt
The text was updated successfully, but these errors were encountered: