Skip to content

feat: generated execution SDK#4776

Draft
yaacovCR wants to merge 2 commits into
graphql:17.x.xfrom
yaacovCR:generate
Draft

feat: generated execution SDK#4776
yaacovCR wants to merge 2 commits into
graphql:17.x.xfrom
yaacovCR:generate

Conversation

@yaacovCR

@yaacovCR yaacovCR commented Jun 1, 2026

Copy link
Copy Markdown
Contributor

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.

  • 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

We also compared with comparable benchmarks to those used by graphql-jit. graphql-jit is 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.

  • 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

@vercel

vercel Bot commented Jun 1, 2026

Copy link
Copy Markdown

@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.

@yaacovCR yaacovCR closed this Jun 3, 2026
@yaacovCR yaacovCR deleted the generate branch June 3, 2026 18:01
@yaacovCR yaacovCR restored the generate branch June 3, 2026 18:01
@yaacovCR yaacovCR reopened this Jun 3, 2026
@yaacovCR yaacovCR mentioned this pull request Jun 15, 2026
yaacovCR added 2 commits June 21, 2026 16:49
Rebase on 17.x.x and carry the static document plus raw runtime variable values through compiled validated execution args so root-selection-set tracing has the execution context it needs.

Simplify compiled execution entrypoints by sharing validated-argument error handling across execute modes.
Rebase on 17.x.x on top of the compile operations commit and keep generated validated execution args compatible with diagnostics tracing by carrying the static document and raw runtime variable values.

Add generated executor kitchen-sink scenarios, a dedicated CI job, and a strict npm run generate:coverage harness for small generated coverage fixtures.

Specialize no-variable generated entrypoints and built-in scalar completions so unreachable generated branches do not block complete V8 range coverage of the targeted generated fixture.

Simplify generated coverage tests and runner edge-path fixtures by factoring repeated executor setup.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant