[performance] Remove per-call char[4] allocation in SKFourByteTag.Parse

[github-actions]

What this does

SKFourByteTag.Parse(string?) allocated a char[4] scratch buffer on every call to pad/truncate an OpenType tag before packing it into a uint. This PR rewrites the body to read the (up to) four characters directly with space padding — no scratch array — and adds an ABI-safe additive Parse(ReadOnlySpan<char>) overload that the string overload delegates to.

public static SKFourByteTag Parse (string? tag) =>
    Parse (tag.AsSpan ());

public static SKFourByteTag Parse (ReadOnlySpan<char> tag)
{
    if (tag.IsEmpty)
        return new SKFourByteTag (0);

    var c1 = tag.Length > 0 ? tag[0] : ' ';
    var c2 = tag.Length > 1 ? tag[1] : ' ';
    var c3 = tag.Length > 2 ? tag[2] : ' ';
    var c4 = tag.Length > 3 ? tag[3] : ' ';

    return new SKFourByteTag (c1, c2, c3, c4);
}

Invariant that keeps it correct: the original packed (byte)c of each of the first four chars, padding missing trailing slots with ' ' and truncating extra chars; IsNullOrEmpty returned tag 0. The new code preserves all of that exactly — null/empty → empty span → 0, the same byte-truncation happens in the existing SKFourByteTag(char,char,char,char) constructor, and space padding is identical.

No public signature changed — one method body changed plus one additive overload. ABI-safe.

Proof it is faster

Standalone New-vs-Old harness (the two exact algorithm bodies; Parse is pure managed, no native call). net10.0, AMD EPYC 7763, .NET 10.0.9 X64 RyuJIT AVX2, 110M calls over a representative tag batch, 3 runs:

Run	Old ns/call	New ns/call	Ratio	Old alloc	New alloc
1	7.54	5.43	0.72	117.7 MB (32 B/call)	0 B
2	5.89	4.11	0.70	0 B*	0 B
3	5.90	3.96	0.67	0 B*	0 B

~30% faster, repeatable. *On modern .NET the JIT escape-analyses the old char[4] and stack-allocates it in the tight steady-state loop (0 B in runs 2-3), but the allocation is real on cold/tier-0 code (run 1 = 32 B/call) and on TFMs without escape analysis (.NET Framework, netstandard2.0 consumers), where the old path allocates 32 B on every call. The new path never allocates on any TFM.

The committed benchmark is benchmarks/SkiaSharp.Benchmarks/Benchmarks/SKFourByteTagParseBenchmark.cs (standard [MemoryDiagnoser] New-vs-Old form). BenchmarkDotNet's default child-process toolchain cannot build the multi-TFM binding in this CI-less environment (same limitation noted in #4369), so the numbers above were taken with an equivalent in-process harness; run it in CI with:

dotnet run -c Release --project benchmarks/SkiaSharp.Benchmarks -- --filter '*SKFourByteTagParseBenchmark*'

Proof it is identical

tests/Tests/SkiaSharp/SKFourByteTagTest.cs gains a bit-exact equivalence suite: a [Theory] comparing the new Parse against a verbatim copy of the original char[4] algorithm across null / empty / 1–6 chars / all-spaces / NUL / chars above 0xFF (low-byte truncation) / surrogate code units, plus tests that the new ReadOnlySpan<char> overload agrees with the string overload (including a span sliced out of a larger string) and that empty/default spans return 0.

• 64/64 SKFourByteTagTest tests pass (net10.0).
• The equivalence test catches a deliberately-wrong result: mutating one padding char to '_' turns the suite red (2 failures), confirming it is a real guardrail.
• The rest of the suite is unchanged.

Label

perf/allocations — the dominant, measured driver is eliminating the per-call char[4] scratch allocation (there is no P/Invoke on this path).

Fixes #4395

---

Produced automatically by the SkiaSharp agentic performance-fixer workflow (via the performance-fixer skill). Scope: managed C# only. Numbers are empirically measured on the named hardware/TFM (not statically reasoned); absolute ns are environment-dependent. ABI impact: none.

Generated by Fixer - Performance · ● 35.9M · ◷

[github-actions]

📖 Documentation Preview

The documentation for this PR has been deployed and is available at:

🔗 View Staging Site
🔗 View Staging Docs
🔗 View Staging Gallery (Blazor)
🔗 View Staging Gallery (Uno Platform)
🔗 View Staging SkiaFiddle

This preview will be updated automatically when you push new commits to this PR.

---

This comment is automatically updated by the documentation staging workflow.

[github-actions]

📦 Try the packages from this PR

Warning

Do not run these scripts without first reviewing the code in this PR.

Step 1 — Download the packages

bash / macOS / Linux:

curl -fsSL https://raw.githubusercontent.com/mono/SkiaSharp/main/scripts/get-skiasharp-pr.sh | bash -s -- 4396

PowerShell / Windows:

iex "& { $(irm https://raw.githubusercontent.com/mono/SkiaSharp/main/scripts/get-skiasharp-pr.ps1) } 4396"

Step 2 — Add the local NuGet source

dotnet nuget add source ~/.skiasharp/hives/pr-4396/packages --name skiasharp-pr-4396

More options

Option	Description
--successful-only / -SuccessfulOnly	Only use successful builds
--force / -Force	Overwrite previously downloaded packages
--list / -List	List available artifacts without downloading
--build-id ID / -BuildId ID	Download from a specific build

Or download manually from Azure Pipelines — look for the nuget artifact on the build for this PR.

Remove the source when you're done:

dotnet nuget remove source skiasharp-pr-4396

[Copilot]

Pull request overview

This PR optimizes SKFourByteTag.Parse by removing the per-call char[4] scratch allocation and introducing an ABI-safe Parse(ReadOnlySpan<char>) overload that the string? overload delegates to, keeping the packed-tag semantics unchanged.

Changes:

• Rewrote SKFourByteTag.Parse(string?) to delegate to a new Parse(ReadOnlySpan<char>) overload, avoiding scratch-buffer allocation.
• Added a comprehensive test suite covering null/empty, padding/truncation, low-byte truncation, and surrogate code-unit behavior.
• Added a BenchmarkDotNet New-vs-Old benchmark for SKFourByteTag.Parse.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
binding/SkiaSharp/SKFourByteTag.cs	Adds Parse(ReadOnlySpan<char>) and rewrites Parse(string?) to delegate, eliminating scratch allocation.
tests/Tests/SkiaSharp/SKFourByteTagTest.cs	Adds theory/fact coverage to validate exact packed results and span/string overload parity.
benchmarks/SkiaSharp.Benchmarks/Benchmarks/SKFourByteTagParseBenchmark.cs	Adds a baseline-vs-new benchmark comparing the original algorithm to the updated implementation.

[mattleibow]

Local benchmark — macOS (real hardware)

Ran the committed SKFourByteTagParseBenchmark locally on Apple Silicon to add a macOS data point alongside the CI/Linux numbers.

Environment: Apple M3 Pro · macOS 26.5 · .NET 10.0.9 (Arm64 RyuJIT) · BenchmarkDotNet 0.13.5 · InProcessEmitToolchain

Method	Mean	Error	StdDev	Ratio	Allocated
Old	206.80 ns	2.697 ns	2.522 ns	1.00	-
New	34.06 ns	0.340 ns	0.284 ns	0.16	-

≈ 6.1× faster (206.8 ns → 34.1 ns) for the 22-tag batch.

Note on allocation: on .NET 10 the JIT stack-allocates the non-escaping char[4], so both rows show - (0 B) here — on this runtime the win is codegen. The heap-allocation removal still applies on runtimes without object stack allocation (.NET Framework / Mono / WASM / AOT).