search

dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
14.95k stars 4.65k forks source link

R2R image of SPC has many costly ValueTuple methods #76513

Open jakobbotsch opened 1 year ago

jakobbotsch commented 1 year ago

I noticed that we spend a lot of JIT time and image size on ValueTuple methods in R2R: https://gist.github.com/jakobbotsch/84a4525207268577fddb1b174b8ea63d

It seems these end up being rooted due to e.g. https://github.com/dotnet/runtime/blob/144a33a01251fce466d7be9b7cafff02f05ae6cc/src/libraries/System.Private.CoreLib/src/System/TupleExtensions.cs#L679-L689

Skipping ToValueTuple and ToTuple methods avoids the root and reduces the size of SPC by around 2% on win-x64. It feels like a safe bet that most of these overloads are not going to be used in most applications, so skipping them would be fruitful in terms of deployment size.

It would also be nice to collect some data such as "X method is responsible for rooting Y bytes in the final image" and see if there are more cases like this that we should consider skipping.

dotnet-issue-labeler[bot] commented 1 year ago

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.

jkoritzinsky commented 1 year ago

It would also be nice to collect some data such as "X method is responsible for rooting Y bytes in the final image" and see if there are more cases like this that we should consider skipping.

I think this idea will become even more interesting after https://github.com/dotnet/runtime/pull/75793 gets in and we only root public (or possibly-public) surface area.

jkotas commented 1 year ago

This leads to partially pre-compiling CoreLib using PGO data. I do not think we would want to maintain the list of what's not worth pre-compiling by hand.

We have experimented with partially compiling CoreLib based on PGO data in the past. Unfortunately, we have seen measurable regressions in number of cases. The problem is that each application uses a substantially different set of one-off methods from CoreLib.

We may want to redo the experiments with partially precompiling CoreLib to see where we would be landing with the current state of tiered JIT.

jakobbotsch commented 1 year ago

I think certainly the heuristics of how generic methods are instantiated can be improved. For example, I don't think it makes sense to instantiate 21-ary value tuple method with 21 instances of System.__Canon without seeing any such caller.

steveisok commented 1 month ago

I know this has had a few milestone bounces, but I think it would be interesting for us to look at in .NET 10.