You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
R2R image of SPC has many costly ValueTuple methods #76513
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.
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 #75793 gets in and we only root public (or possibly-public) surface area.
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.
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.
Activity
jkoritzinsky commentedon Oct 3, 2022
I think this idea will become even more interesting after #75793 gets in and we only root public (or possibly-public) surface area.
jkotas commentedon Oct 3, 2022
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 commentedon Oct 3, 2022
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.__Canonwithout seeing any such caller.steveisok commentedon Aug 8, 2024
I know this has had a few milestone bounces, but I think it would be interesting for us to look at in .NET 10.
mangod9 commentedon Jul 7, 2025
@jakobbotsch, assume this is still a concern?