UnigramDev/Unigram/develop • a0f0499 • 36 files, +3941/-0 Add a benchmark harness for the TDLib JSON

UnigramDev/Unigram/develop • a0f0499 • 36 files, +3941/-0
Add a benchmark harness for the TDLib JSON path

Measures what Client.Receive and ClientJson.FromJson actually cost per payload,
on all three toolchains in play: the desktop JIT under BenchmarkDotNet, UWP on
.NET 10 with NativeAOT, and UWP on .NET Native, which is what ships. One Suite.cs
runs on all three so their numbers line up row for row.

Nothing here touches the app. The projects reference Telegram.Generators and
Libraries/tdjson/td_api.tl and link ClientJson.cs, so the code under test is the
generated parser rather than a copy that would drift from it. Round trips go
through the real tdjson.dll using TDLib's own offline test methods, which need no
account and no network.

Findings are written up in Telegram.Benchmarks/README.md. The load-bearing one:
UWP resolves System.Memory's netstandard2.0 asset, so Span<T> is not the runtime's
own and indexing one costs ~10x what the same access over byte[] or byte* costs.
That accounts for the parse being ~3x slower on .NET Native than the desktop
numbers suggested, and it is why Json/TdJsonReader.cs walks raw memory instead:
3.1-3.7x faster than Utf8JsonReader there, with the same allocations.

That reader is a prototype and is not wired into the generator yet. It is
bounds-checked against truncated input, proven by a guard-page sweep over every
prefix of every corpus payload - 70,512 of them - and Validation.cs runs on all
three hosts, so agreement with Utf8JsonReader is checked against the
netstandard2.0 System.Text.Json as well as the net10.0 one.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

#unigram