[Blazor WASM] - Investigate 8% size regression in System.Memory.dll.br

[SamMonoRT]

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

Tagging subscribers to this area: @GrabYourPitchforks, @carlossanlop
See info in area-owners.md if you want to be subscribed.

Issue Details

---

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

Author:	SamMonoRT
Assignees:	-
Labels:	area-System.Memory, untriaged
Milestone:	-

[GrabYourPitchforks]

@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.

[SamMonoRT]

I don't have that information. I just saw an auto-filled issue by @DrewScoggins which has some more information : DrewScoggins/performance-2#5087

[DrewScoggins]

Do you need the trimmed files or the actual full binaries from the NETCore.App package?

[DrewScoggins]

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

Benchmark	Baseline	Test	Test/Base	Baseline IR	Compare IR	IR Ratio	Baseline ETL	Compare ETL
SOD - New Blazor Template - Publish - pub/wwwroot/_framework/System.Collections.dll	22.00 KB	23.50 KB	1.07
SOD - New Blazor Template - Publish - pub/wwwroot/_framework/System.Text.Json.dll.br	79.08 KB	83.19 KB	1.05
SOD - New Blazor Template - Publish - pub/wwwroot/_framework/System.Memory.dll	17.50 KB	19.00 KB	1.09
SOD - New Blazor Template - Publish - Aggregate - .dll	2.09 MB	2.12 MB	1.01
SOD - New Blazor Template - Publish - pub/wwwroot/_framework/System.Text.Json.dll	240.50 KB	253.00 KB	1.05
SOD - New Blazor Template - Publish - pub/wwwroot/_framework/System.Collections.Concurrent.dll	17.00 KB	17.50 KB	1.03
SOD - New Blazor Template - Publish - pub/wwwroot/_framework/System.Collections.dll.gz	9.79 KB	10.45 KB	1.07
SOD - New Blazor Template - Publish - pub/wwwroot/_framework/System.ObjectModel.dll.br	2.74 KB	2.77 KB	1.01
SOD - New Blazor Template - Publish - pub/wwwroot/_framework/System.Memory.dll.gz	8.59 KB	9.26 KB	1.08
SOD - New Blazor Template - Publish - pub/wwwroot/_framework/System.Text.Json.dll.gz	92.47 KB	97.24 KB	1.05
SOD - New Blazor Template - Publish - pub/wwwroot/_framework/System.Memory.dll.br	7.72 KB	8.26 KB	1.07
SOD - New Blazor Template - Publish - pub/wwwroot/_framework/System.Collections.dll.br	8.82 KB	9.38 KB	1.06

Historical Data in Reporting System

Repro

git clone https://github.com/dotnet/performance.git
python3 .\performance\scripts\benchmarks_ci.py -f netcoreapp5.0 --filter 'SOD - New Blazor Template - Publish*'

Histogram

SOD - New Blazor Template - Publish

Docs

Profiling workflow for dotnet/runtime repository
Benchmarking workflow for dotnet/runtime repository

[GrabYourPitchforks]

The files after trimming but before compression would be best. That way I can plug the whole mess through ilspy and see what changed.

[DrewScoggins]

Baseline
Compare

[DrewScoggins]

I am also going to make a change so that these artifacts are preserved by Helix, as reproducing them took me about 30 minutes.

[GrabYourPitchforks]

Sorry, I should clarify: I need all files, not just System.Memory.dll. Otherwise I can't go back in the call graph.

[DrewScoggins]

Oh, sorry about that. Here is what you need.

Baseline
Compare

[GrabYourPitchforks]

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.

[GrabYourPitchforks]

My best guess is that this is a consequence of #51025. The JSON stack now has direct dependencies to JsonNode which can't be trimmed away, and JsonNode itself has direct dependencies to ArrayBufferWriter<T> which can't be trimmed away.

runtime/src/libraries/System.Text.Json/src/System/Text/Json/Node/JsonNode.To.cs

Lines 47 to 54 in ccc25a9

	var output = new ArrayBufferWriter<byte>();
	using (var writer = new Utf8JsonWriter(output, options))
	{
	WriteTo(writer);
	}
	return JsonHelpers.Utf8GetString(output.WrittenSpan);

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 though ArrayBufferWriter<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");
	}
}