Repository navigation
[Blazor WASM] - Investigate 8% size regression in System.Memory.dll.br #51571
Description
Activity
@SamMonoRT Do you have the raw files on disk for the before and after images? That would definitely help investigation, since we could look at the entire call graph and see if the regression was due to code within System.Memory or is due to changes in one of its callers.
I don't have that information. I just saw an auto-filled issue by @DrewScoggins which has some more information : DrewScoggins/performance-2#5087
Do you need the trimmed files or the actual full binaries from the NETCore.App package?
I will also copy over the full contents of the auto-filed issues, as it contains a few other dlls that have small regressions as well.
Run Information
Architecture x64 OS ubuntu 18.04 Baseline 7fa839a727e510f2b1b104eafb2c1fb339249756. Compare ee0719079c4c4540f5adb135f002ad3ecf6c25ea Diff Diff Regressions in SOD - New Blazor Template - Publish
Historical Data in Reporting SystemRepro
git clone https://github.com/dotnet/performance.git python3 .\performance\scripts\benchmarks_ci.py -f netcoreapp5.0 --filter 'SOD - New Blazor Template - Publish*'
Details
Histogram
SOD - New Blazor Template - Publish
Docs
Profiling workflow for dotnet/runtime repository
Benchmarking workflow for dotnet/runtime repositoryThe files after trimming but before compression would be best. That way I can plug the whole mess through ilspy and see what changed.
I am also going to make a change so that these artifacts are preserved by Helix, as reproducing them took me about 30 minutes.
Reacted by Ryan LuciaSorry, I should clarify: I need all files, not just System.Memory.dll. Otherwise I can't go back in the call graph.
The trimmed compare file graph contains lots of code to support
ArrayBufferWriter<T>- this code wasn't in the trimmed baseline graph. I'm still trying to track down who is calling this.
My best guess is that this is a consequence of #51025. The JSON stack now has direct dependencies to
JsonNodewhich can't be trimmed away, andJsonNodeitself has direct dependencies toArrayBufferWriter<T>which can't be trimmed away.Specifically, the above code instantiates an
ArrayBufferWriter<T>and passes it around, which means the linker needs to keep all the method implementations around. Previously, even thoughArrayBufferWriter<T>still existed as a type (because the JSON stack had a field reference to it), the linker had been nuking all of the method implementations.// System.Buffers.ArrayBufferWriter<T> - BASELINE using System; using System.Buffers; using System.Runtime.CompilerServices; public sealed class ArrayBufferWriter<T> : IBufferWriter<T> { public ReadOnlyMemory<T> WrittenMemory { [MethodImpl(MethodImplOptions.NoInlining)] get { throw new NotSupportedException("Linked away"); } } public ReadOnlySpan<T> WrittenSpan { [MethodImpl(MethodImplOptions.NoInlining)] get { throw new NotSupportedException("Linked away"); } } public int WrittenCount { [MethodImpl(MethodImplOptions.NoInlining)] get { throw new NotSupportedException("Linked away"); } } [MethodImpl(MethodImplOptions.NoInlining)] public void Clear() { throw new NotSupportedException("Linked away"); } [MethodImpl(MethodImplOptions.NoInlining)] public void Advance(int count) { throw new NotSupportedException("Linked away"); } [MethodImpl(MethodImplOptions.NoInlining)] public Memory<T> GetMemory(int sizeHint = 0) { throw new NotSupportedException("Linked away"); } }
Related to #51311.
The JSON stack now has direct dependencies to JsonNode which can't be trimmed away
FWIW the node types can't be trimmed away today because it is rooted by these converters which are in turn rooted by this logic, which happens when existing
JsonSerializerOptions-based methods ofJsonSerializerare used. When Blazor is updated to use new metadata-based APIs onJsonSerializer(dotnet/aspnetcore#31877), I expect that these converters will be trimmed out if not needed by the application.
cc @steveharter on thoughts on whether we can minimize the dependency on
ArrayBufferWriter<T>for apps that use the node feature.We can change the implementation to use
PooledByteBufferWriterinstead. That is what the non-Stream paths use today (the Stream paths useArrayBufferWriter<T>.Thanks for the quick change, resulted in decrease in size :
- ghost locked as resolved and limited conversation to collaborators
on May 28, 2021
Size increase for System.Memory.dll.br as observed from https://msit.powerbi.com/groups/me/apps/54e0e83f-07bc-45bf-87b7-a7677ff3af2a/dashboards/fa051820-ff60-4d40-8a08-bdcc1b47b1d0
cc @CoffeeFlux