[System.Text.Json] Fix ARM64 Utf8JsonReader regression

[jozkee]

Fixes#131600.

Restore the explicit comparison form for the number terminator check in Utf8JsonReader.TryGetNumber. The pattern-matching form is semantically equivalent, but introduced a large Linux ARM64 regression in System.Text.Json.Tests.Perf_Get.GetUInt64.

Performance

EgorBot on an Azure Ampere ARM64 machine measured the regressed pattern form against the selectively restored reader code:

State	Mean	Ratio
Pattern form (43560bc7)	900.8 ns	1.00
Restored reader comparisons	515.4 ns	0.57

The cumulative bisection further narrowed the transition from 515.6 ns at fa936cfa to approximately 896 ns after this condition changed. The intervening commits only modify Debug.Assert expressions in Release builds.

Results:

• Benchmarks for dotnet/runtime#132430 (for @jozkee) EgorBot/Benchmarks#508 (comment)
• Benchmarks for dotnet/runtime#132430 (for @jozkee) EgorBot/Benchmarks#509 (comment)

Note

This pull request description was prepared with GitHub Copilot.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-text-json
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR adjusts Utf8JsonReader’s numeric parsing logic by replacing a byte pattern-matching check with explicit comparisons in the TryGetNumber integer-digit path, aiming to address an ARM64 performance regression in number reading.

Changes:

• Replaced is not ((byte)'.' or (byte)'E' or (byte)'e') with explicit != comparisons in the non-leading-zero integer parsing path.
• Kept the surrounding control flow and exception behavior intact, focusing the change narrowly on the terminator check shape.

Suppressed comments (1)

src/libraries/System.Text.Json/src/System/Text/Json/Reader/Utf8JsonReader.cs:1512

• This change restores explicit comparisons in the non-leading-zero integer path, but the same “number terminator” check still uses the pattern-matching form in ConsumeZero (nextByte is not ((byte)'.' or (byte)'E' or (byte)'e')) which is also reached via TryGetNumber when the value starts with '0'. If the goal is to fully avoid the regressed code shape for number parsing, this should likely be updated as well to keep the parser consistent across both leading-zero and non-leading-zero paths.

 if (nextByte != '.' && nextByte != 'E' && nextByte != 'e')
{
_bytePositionInLine += i;
ThrowHelper.ThrowJsonReaderException(ref this, ExceptionResource.ExpectedEndOfDigitNotFound, nextByte);
}

[eiriktsarpalis]

Approving this to unblock the regression, but I think we might want to look closer at how pattern matching codegen is handled here cc @dotnet/roslyn

[jjonescz]

Possibly related: dotnet/roslyn#80052

[jozkee]

I checked the IL for every pattern shape touched in this PR using .NET Lab. This is the Roslyn lowering tracked by dotnet/roslyn#80052.

In every shape, the is-pattern form lowers to strictly heavier IL than the equivalent &&/|| comparison chain.

Shape	is method	size / locals / maxstack	!=/== method	size / locals / maxstack
A: not (. or E or e)	Test1	32 B, 1 local, stack 2	Test2	22 B, 0 locals, stack 8
B: not (E or e)	Test3	25 B, 1 local, stack 2	Test4	17 B, 0 locals, stack 8
C: + or -	Test5	22 B, 1 local, stack 2	Test6	14 B, 0 locals, stack 8
D: e or E	Test7	22 B, 1 local, stack 2	Test8	14 B, 0 locals, stack 8
E: not (Slash or Asterisk)	Test9	25 B, 1 local, stack 2	Test10	17 B, 0 locals, stack 8

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

[jozkee]

/backport to release/11.0-rc1

[github-actions]

Started backporting to release/11.0-rc1 (link to workflow run)