feat: generated execution SDK#4776
Draft
yaacovCR wants to merge 2 commits into
Draft
Conversation
|
@yaacovCR is attempting to deploy a commit to the The GraphQL Foundation Team on Vercel. A member of the Team first needs to authorize it. |
Add a compiled execution path for validated operations and subscriptions. Benchmarks were run on Node v24.14.1 against 17.x.x. The compiler path shows rough ops/sec wins across the benchmark scenarios: - async root fields: 1,511 vs 638 ops/sec, +137% - field argument values: 11,245 vs 3,595 ops/sec, +213% - introspection query: 70.4 vs 49.9 ops/sec, +41% - async list field: 6,725 vs 3,083 ops/sec, +118% - async non-null list items: 6,853 vs 2,960 ops/sec, +132% - sync list field: 44,583 vs 14,248 ops/sec, +213% - variable field collection: 18,498 vs 5,708 ops/sec, +224%
Add source generation for specialized execution modules. Benchmarks were run on Node v24.14.1 against 17.x.x, with the compiled executor parent included as an additional comparison. The generated path shows these rough ops/sec changes: - async root fields: 1,994 vs 633 ops/sec, +215% vs 17.x.x and +32% vs compiled - field argument values: 19,698 vs 3,556 ops/sec, +454% vs 17.x.x and +79% vs compiled - introspection query: 117 vs 49.8 ops/sec, +135% vs 17.x.x and +66% vs compiled - async list field: 9,905 vs 3,115 ops/sec, +218% vs 17.x.x and +49% vs compiled - async non-null list items: 9,719 vs 2,939 ops/sec, +231% vs 17.x.x and +42% vs compiled - sync list field: 60,523 vs 14,355 ops/sec, +321% vs 17.x.x and +38% vs compiled - variable field collection: 101,957 vs 5,631 ops/sec, +1,711% vs 17.x.x and +444% vs compiled The generated reference benchmark scenarios mirror graphql-jit benchmark shapes, with README numbers included in the benchmark files as hardware-dependent context. The local run produced: - few resolvers: 245,154 vs 17,336 ops/sec, +1,313% vs 17.x.x and +522% vs compiled - reference introspection: 3,323 vs 1,463 ops/sec, +127% vs 17.x.x and +62% vs compiled - many resolvers: 129,955 vs 11,138 ops/sec, +1,066% vs 17.x.x and +350% vs compiled - nested arrays: 872 vs 129 ops/sec, +579% vs 17.x.x and +90% vs compiled The main remaining performance gap to graphql-jit appears to come from preserving graphql-js 17.x null-prototype semantics not just for result objects, but also for runtime maps such as inputs, variables, and argument values.
This was referenced Jun 2, 2026
Open
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
1 participant
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.
Depends on:
Add source generation for specialized execution modules.
Benchmarks were run on Node v24.14.1 against 17.x.x, with the compiled executor parent included as an additional comparison.
The generated path shows these rough ops/sec changes compared to regular execution, with percentage comparison to compilation only also included.
We also compared with comparable benchmarks to those used by
graphql-jit.graphql-jitis still faster! The remaining performance gap possibly largely coming from preserving graphql-js 17.x null-prototype semantics for runtime maps including all results objects and all inputs.Below numbers compare the generated SDK performance to regular execute, with percentage comparison to compilation also included.