UnigramDev/Unigram/develop • c04e326 • 10 files, +217/-118
Build one parser or the other, never both

TdPointerParser was a flag that added the pointer parsers to the reader ones;
TdParsers is a choice between them - Reader, Pointer, or Both. The app has no
use for two parsers over one schema: it is 44,508 generated lines of .NET
Native compile time for a set nothing calls.

The property is what the generator reads, and it now emits either set or both.
The constants it pairs with, TD_READER_PARSER and TD_POINTER_PARSER, are what
the hand-written code reads, so ClientJson, Client and ClientService compile
exactly the half that was generated - the entry points, ParseObject, the
reading half of Utf8JsonExtensions, the interface overloads and their
implementations. The writing half stays in every mode: requests are serialized
with Utf8JsonWriter whichever parser was generated.

Both is Telegram.Benchmarks, whose whole argument is the two of them racing
over one corpus and agreeing field for field. Deleting the reader set from the
generator would delete the cross-check that says the pointer parsers are right,
so nothing is deleted - which also means Reader walks the app back in one edit.

Generated lines: Reader 149,712, Pointer 167,143, Both 211,651. Reader is still
byte for byte what shipped. All three compile - the throwaway project builds
Client.cs, ClientJson.cs and the generated file in each - except ClientService,
whose #if blocks nothing here can compile. The app stays on Both until the
pointer path has been built and run once.

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

UnigramDev/Unigram/develop • 2e431bf • 4 files, +53/-3
Charge file handling separately from parsing

Files are re-entered through ClientResultHandler mid-payload, so a dictionary
lookup, a FileExists syscall the first time an id is seen and an
EventAggregator publish all happen inside the interval Record measures. At
startup a chat list is hundreds of files never seen before, and every bit of
that was being charged to the parser.

CommitFile is timed on its own, the rates are over the parse with it taken
out, and the total is still shown beside them - that one is what an update
really costs, the other is what compares to the benchmark.

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

UnigramDev/Unigram/develop • a812a15 • 4 files, +46/-2
Count the file existence checks separately too

FileExists is already GetFileAttributesExFromAppW, one metadata syscall behind
a WinRT hop - there is no faster call to swap in, so the only moves left are
making it rarer or moving it off the TDLib thread. Both depend on how many
there are, which nothing here knows: the check only runs for a file seen for
the first time whose download is already complete.

So it is counted and timed on its own before anything is redesigned around it.

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

#unigram