Add QBS versus generated C benchmark - #66
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Add a same-schema benchmark comparing generated C with QBS-driven generic C. Both paths use
benchmarks/schemas/workload.brd; QBS is generated at build time throughquarry-schema-compiler --emit-qbs, and one initialized logical workload feeds both adapters. Correctness gates run before timing.Correctness
get_value() -> ARRAY -> record_array_get()path: PASSPerformance baseline
QBS parse: 355 ns/parse (2.82M parses/s). Ratios are approximately 3.2x for encode and 2.8x for post-validation access. These are optimized local measurements, not universal performance claims.
Schema-artifact footprint
The 15.3x object/QBS ratio compares schema-specific artifacts only; it is not a complete application-footprint ratio. Both approaches require runtime/support code.
Generated object details: root
.text8,013 bytes/read-only 376 bytes; imported.text3,485 bytes/read-only 108 bytes. Source/header counts are build-artifact measurements, not executable footprint.Memory and integration
Configured parser/validation workspace is 13,056 bytes; exact consumed minimum is not exposed by the public API. Shared BRF buffers are treated consistently. The QBS comparison is integrated into the common benchmark runner, and generated object sections are printed through
llvm-sizewhen available.Validation
Optimized benchmark build/run, common runner, strict C99 benchmark build, BRF equality, checksum equality, complete CTest (52/52), and
git diff --checkall pass.Compatibility
Benchmark-only change. No production compiler/runtime, API/ABI, BRF, QBS, Schema IR, or compatibility epoch changes.
Deferred work
Embedded footprint, exact incremental generic-runtime attribution, multi-schema scaling, and production performance optimization are deferred. This PR establishes the pre-optimization baseline.