Improve shared parser inlining and generated code layout

[Altren]

Reading vectors of structs still leaves small parser helpers out of line and error-handling code mixed into hot functions in optimized builds. Explicitly inline scalar parsing and vector-element parsing, and mark eight existing error branches as unlikely. This improves generated code layout and slightly reduces code size, with read improvements both without LTO and with ThinLTO.

The shared-parser changes are:

• Add RFL_ALWAYS_INLINE to ParserBasicType::read.
• Move VectorReader's local parsing lambda into an explicitly inlined private parse method. The insertion logic is unchanged.
• Extend the existing use of [[unlikely]] to failed field reads, failed object/array reads, and collected-error checks in ViewReader and NamedTupleParser.

Benchmarks

Compare with upstream main at 10fb6bb. The checked-in parser_inlining read benchmarks cover 100,000 records with either two or sixteen float fields; this PR adds matching YAS cases. A local extended harness uses those same schemas to measure reads and writes, and adds native serializer references for all four formats.

A separate local Dataset-only harness measures all four formats using a nested Dataset: 500 groups, each containing 3,000 Point2 { double x; double y; } values and 3,000 uint64_t IDs. Dataset rows below come from this new run; record rows retain their original measurements. Both gains and losses are subject to the same 3% cutoff.

All reflect-cpp cases use ordinary rfl::<format>::write/read, without custom parsers or field annotations. Native references use Cereal portable binary archives, YAS binary archives, yyjson directly, and MessagePack C directly. The native JSON and MessagePack converters are handwritten for these schemas, retaining field names and checking required fields and numeric types; they are reference implementations, not replacements for reflect-cpp's general parsing and error-aggregation semantics.

Input generation and equality checks are outside the timers. Reads include byte decoding, C++ object construction, and destruction. Writes include encoding into an owned byte container and its destruction. Cereal uses the same memory-stream construction and copies on both sides. YAS uses memory buffers; JSON and MessagePack include their DOM/tree conversion. Read fixtures are serialized before timing. No filesystem I/O is timed.

Apple Clang 21, macOS arm64, C++20, Release -O3 -DNDEBUG. Median CPU times from six runs per configuration, with at least 0.1 s warmup, 40 measured iterations per record case, and 10 measured iterations per Dataset case. Baseline, patched, and native configurations are rotated and reversed between runs. ThinLTO is enabled on benchmark code and the reflect-cpp core, including yyjson and the final link; MessagePack C and Google Benchmark are the same separately built libraries in all configurations.

All times are milliseconds. Gain = old / new; above 1.00× is faster. Native serializer comparisons are provided separately below the PR description. Changes below 3% in measured CPU time are treated as noise. A row is shown only if the absolute change reaches 3% in at least one build configuration; an em dash in a Gain cell means that configuration is below the cutoff. The cutoff uses unrounded measurements.

Reads

Format	Data	Bytes	Old, no LTO	New, no LTO	Gain	Old, ThinLTO	New, ThinLTO	Gain
Cereal	Record2	800,009	1.627	1.222	1.33×	0.982	0.793	1.24×
Cereal	Record16	6,400,009	11.531	9.584	1.20×	8.738	7.319	1.19×
JSON	Record2	3,683,353	2.678	2.479	1.08×	2.335	2.343	—
MessagePack	Record2	2,500,014	2.880	2.551	1.13×	2.356	2.225	1.06×
MessagePack	Record16	20,100,014	27.310	26.350	1.04×	27.050	26.575	—
YAS	Record2	800,015	1.265	1.048	1.21×	0.423	0.397	1.07×
YAS	Record16	6,400,015	7.082	6.842	1.04×	4.241	3.228	1.31×
Cereal	Dataset	36,008,009	24.224	17.401	1.39×	13.383	12.230	1.09×
JSON	Dataset	70,124,332	50.572	47.977	1.05×	42.971	43.573	—
MessagePack	Dataset	48,009,011	61.761	57.234	1.08×	47.198	46.890	—
YAS	Dataset	36,008,015	20.063	17.124	1.17×	7.426	2.320	3.20×

The original record fixtures and all four new Dataset fixtures are byte-identical across all six baseline/patched/native and LTO/no-LTO configurations. Every reader successfully decodes the baseline output and reproduces every field. These are local measurements; gains depend on compiler, link configuration, schema, and workload. The patch changes read-side code only; writes are measured as a control.

Generated code layout and size

The compiler has more freedom to optimize the successful path after helper inlining and error-branch hints. The original four-format, read-only record benchmark executable (without the extended native/write/nested cases above) has a smaller machine-code section in both configurations:

Build	Before __text	After __text	Change
Without LTO	897,896 bytes	855,532 bytes	-4.7%
ThinLTO	507,600 bytes	474,984 bytes	-6.4%

These are executable __text section sizes measured with llvm-objdump, not total file sizes or debug information. The executable includes the shared benchmark infrastructure and verification driver in both variants. Code-size results may differ for other programs.

Validation

Run the checked-in reflect-cpp record read cases with (the local native, write, and nested comparisons above use an extended harness):

./build/benchmarks/all/reflect-cpp-all-format-benchmarks \
  --benchmark_filter=parser_inlining \
  --benchmark_min_warmup_time=0.1 \
  --benchmark_min_time=40x \
  --benchmark_repetitions=6

For a local LTO comparison, build the same sources separately with CMAKE_INTERPROCEDURAL_OPTIMIZATION=OFF and ON in Release mode.

Informational comparison: reflect-cpp vs native serializers

This is context for the absolute performance of reflect-cpp, not evidence for this PR’s improvement. New is the build with this PR; Native uses ordinary Cereal/YAS archives or the C library plus a handwritten schema converter for JSON/MessagePack. Ratio = New / Native: above 1× means reflect-cpp takes more time.

Median CPU times from six rotated/reversed runs per configuration, with 0.1 s warmup and at least 0.25 s measured CPU time per case. Compiler, optimization flags, libraries, timed ownership/copying, and input generation follow the methodology above. All 12 fixtures are byte-identical across old-native, revised-native, and patched-reflect-cpp builds, both with and without ThinLTO; every reader reproduces the baseline data. Separate semantic checks cover reordered/duplicate/unknown fields and invalid inputs.

Reads

Format	Data	New, no LTO	Native, no LTO	New / Native	New, ThinLTO	Native, ThinLTO	New / Native
Cereal	Record2	1.267	0.749	1.69×	0.797	0.741	1.08×
Cereal	Record16	9.604	6.207	1.55×	7.347	5.883	1.25×
JSON	Record2	2.466	2.248	1.10×	2.324	2.102	1.11×
MessagePack	Record2	2.577	2.085	1.24×	2.335	2.108	1.11×
MessagePack	Record16	26.375	26.594	0.99×	26.758	26.771	1.00×
YAS	Record2	1.038	0.165	6.31×	0.402	0.225	1.79×
YAS	Record16	6.975	1.311	5.32×	3.190	2.836	1.13×
Cereal	Dataset	18.797	11.698	1.61×	12.345	12.388	1.00×
JSON	Dataset	47.470	42.802	1.11×	43.214	41.555	1.04×
MessagePack	Dataset	58.247	44.598	1.31×	47.862	46.189	1.04×
YAS	Dataset	17.526	4.076	4.30×	7.067	5.134	1.38×

Writes

Format	Data	New, no LTO	Native, no LTO	New / Native	New, ThinLTO	Native, ThinLTO	New / Native
Cereal	Record2	1.001	0.796	1.26×	0.832	0.854	0.97×
Cereal	Record16	7.074	6.836	1.03×	7.369	6.834	1.08×
MessagePack	Record16	18.332	22.014	0.83×	22.036	15.458	1.43×
Cereal	Dataset	15.658	12.664	1.24×	13.535	12.928	1.05×

[Altren]

Also I was thinking if a raw serialization vs reflect-cpp serialisation based on the same library benchmark would be useful in the repository. I understand that reflect-cpp does a bit more in terms of error handling vs raw serializer. But in theory perfect world implementation for the rfl::ceral::write should be as fast as generic handwritten cereal serializer.
My current implementation is far from perfect. Some serializers are easy to do (f.e. cereal), while others are not so simple (f.e. my msgpack implementation is 1.2x slower than rfl::msgpack::write)

[Altren]

I'll also try to investigate why YAS is still so much slower, even after all my improvements that bring other formats close to baseline.

[Altren]

While testing #744 with Linux+GCC I found that this PR decrease LTO GCC performance by ~40% and increase no-LTO by ~25%, so I guess it might be better cancel this PR even with clear win-win on clang on MacOS

[liuzicheng1987]

@Altren OK, if you think that it is better to cancel the PR, then do so.

[Altren]

I'll try to make it good on lixux+gcc and macos+clang. Doing experiments takes much more time, but I think I can get to a point where reflect-cpp is within 20-30% of perfect result, unlike now where f.e. native YAS can be 80% faster.

@liuzicheng1987 Another topic. What do you think about about adding perfect result benchmark into repo? My second message in the PR

[liuzicheng1987]

@Altren yes, I think adding a "perfect result benchmark" for cereal, yas, etc would be a very good idea. We have something like this for JSON and it would be interesting to see that for these formats as well.

[liuzicheng1987]

@Altren by the way, I would also like to do a release quite today.

I will do a 0.26.0 release for now, but I think we should move this out of beta (ergo a 1.0.0 release) once I have made a decision on how to proceed with #719.

So, in other words, we will have another release quite soon.

I am also going to move the repo to a different account, but that shouldn't affect your work too much.

[liuzicheng1987]

@Altren But I think that performance improvements should be a major goal moving forward. We are still slower than YYJSON on most benchmarks. Not by much, so it wasn't something I cared about in the past, but I think now is the time to really close that gap.

[Altren]

I fugured out what was the issue and also added one more commit into this branch. Would be great if it will get into release

[Altren]

The Cereal LTO write slowdown is sensitive to executable layout. The generated serialization loops retain the same instructions and calls. Relinking the same compiled objects with a shared writer-function order removes the main/new timing gap in both cases.

This control establishes a role for linked layout, not extra serialization work. The linker order is diagnostic only and is not part of the patch; the original timing observations remain valid for their executable. Differences below 3% are treated as noise.

The current revision was also checked against the earlier GCC regressions:

Record2 reads, GCC 15.2 / Linux x86-64	No-LTO speedup	LTO speedup
Cereal, default	1.05–1.25×	0.98–1.17×
Cereal, FailFast	1.25×	1.04–1.24×
YAS, default	1.35–1.50×	1.05–1.17×
YAS, FailFast	3.07–3.42×	1.07–1.08×