[NativeAOT] Investigate AOT size savings opportunities around async #79204
Comments
|
Tagging subscribers to this area: @dotnet/area-system-runtime-compilerservices Issue Details.NET Native had size optimizations in the structuring of the BCL code to avoid unnecessary generic expansions in the async infrastructure. We lost these when CoreLibs between the projects were unified. We restored some of it (example: dotnet/corert#6913), but there is likely more that we could do. We could study the old optimizations in the history of the CoreRT repo, or do a new investigation. Not sure how much async changed between then and now. @eerhardt saw that in a sample 20 MB app using npgsql package, 3 MB of stuff come from the CompilerServices namespace and that feels still a bit excessive.
|
|
Would an API like a if (!RuntimeFeature.IsDynamicCodeCompiled && RuntimeFeature.IsSizeOptimized)
{
// Use the common interface as generic parameter.
}
else
{
// Use the struct as generic parameter.
} |
I don't know if any of the optimizations .NET Native had meaningfully affected throughput and would have to be guarded. dotnet/corert#6913 is not something that would really need to be guarded. It helps everywhere (less jitting, less working set). |
|
Here's the MstatDumper dump of the npgsql app, in case anyone is interested in the full output. And tweaking that code to just dump what is in the |
Contributes to dotnet#79204. I don't know if this will be considered mergeable, but I wanted to at least try something. For apps that use async a lot (like the Stage2 app we use for Goldilocks), the async infrastructure can cost 10% of the entire executable. Shuffling a couple things in `GetStateMachineBox` I was able to get 0.23% saving. It's miniscule. In general async is death by a thousand papercuts so I don't see a silver bullet.
Contributes to #79204. I don't know if this will be considered mergeable, but I wanted to at least try something. For apps that use async a lot (like the Stage2 app we use for Goldilocks), the async infrastructure can cost 10% of the entire executable. Shuffling a couple things in `GetStateMachineBox` I was able to get 0.23% saving. It's miniscule. In general async is death by a thousand papercuts so I don't see a silver bullet.
Contributes to dotnet#79204. I don't know if this will be considered mergeable, but I wanted to at least try something. For apps that use async a lot (like the Stage2 app we use for Goldilocks), the async infrastructure can cost 10% of the entire executable. Shuffling a couple things in `GetStateMachineBox` I was able to get 0.23% saving. It's miniscule. In general async is death by a thousand papercuts so I don't see a silver bullet.
Contributes to dotnet#79204. I don't know if this will be considered mergeable, but I wanted to at least try something. For apps that use async a lot (like the Stage2 app we use for Goldilocks), the async infrastructure can cost 10% of the entire executable. Shuffling a couple things in `GetStateMachineBox` I was able to get 0.23% saving. It's miniscule. In general async is death by a thousand papercuts so I don't see a silver bullet.
.NET Native had size optimizations in the structuring of the BCL code to avoid unnecessary generic expansions in the async infrastructure.
We lost these when CoreLibs between the projects were unified. We restored some of it (example: dotnet/corert#6913), but there is likely more that we could do. We could study the old optimizations in the history of the CoreRT repo, or do a new investigation. Not sure how much async changed between then and now.
@eerhardt saw that in a sample 20 MB app using npgsql package, 3 MB of stuff come from the CompilerServices namespace and that feels still a bit excessive.
The text was updated successfully, but these errors were encountered: