Skip to content

Resolve synchronous fields without futures in async execution - #1419

Open
LegNeato wants to merge 5 commits into
graphql-rust:masterfrom
LegNeato:sync-fast-path
Open

Resolve synchronous fields without futures in async execution#1419
LegNeato wants to merge 5 commits into
graphql-rust:masterfrom
LegNeato:sync-fast-path

Conversation

@LegNeato

@LegNeato LegNeato commented Nov 1, 2026

Copy link
Copy Markdown
Member

This PR builds on #1418. Only its last commit is new. It is the last of the five stacked PRs that speed up execution.

  • The macros mark the fields without an async resolver with the new Field::synchronous() method.
  • RootNode finds the types that resolve without awaiting when it builds the schema. An interface field is synchronous if it is synchronous in all implementers. Recursive types form cycles, so the search removes candidates until no candidate changes.
  • The asynchronous executor resolves a synchronous field of a synchronous type in place with GraphQLValue::resolve_field(), without a future. Executor::resolve_async() calls GraphQLValue::resolve() for values of synchronous types.
  • The Book explains which fields resolve without futures.

With synchronous resolvers, asynchronous execution now makes as many allocations as synchronous execution, and it runs as fast. On the benchmarks of #1413 except introspection, it takes 13 to 67% less time than with #1418. With async fn resolvers, scalars and enums resolve without futures, and execution takes up to 8% less time.

The table compares master with this PR and the four PRs before it. It shows the median time per request on an Apple M1 Pro. Synchronous execution takes 17 to 69% less time than on master, and asynchronous execution takes 20 to 87% less time. With synchronous resolvers and with async fn resolvers, juniper is now faster than async-graphql and apollo-compiler on every operation.

Operation juniper_sync juniper juniper_async_fn async_graphql apollo_compiler
minimal 1.99 µs → 1.64 µs 2.42 µs → 1.66 µs 2.39 µs → 1.91 µs 4.99 µs 3.41 µs
flat_list 1.4 ms → 437 µs 3.15 ms → 436 µs 3.11 ms → 999 µs 1.87 ms 1.67 ms
nested_lists 1.16 ms → 374 µs 2.83 ms → 374 µs 2.81 ms → 1.06 ms 1.58 ms 1.61 ms
star_wars 72.7 µs → 31.6 µs 157 µs → 31.1 µs 157 µs → 64.7 µs 121 µs 112 µs
fragments 51.5 µs → 27.5 µs 94.6 µs → 27.7 µs 94.4 µs → 40.3 µs 73.7 µs 67.4 µs
introspection 453 µs → 187 µs 458 µs → 188 µs 452 µs → 185 µs 634 µs —
introspection_without_one_of 451 µs → 186 µs 455 µs → 188 µs 447 µs → 182 µs 613 µs 559 µs

@LegNeato
Stop allocating executor state for every field
fd3dc68 
## Why

The executor allocated for every resolved field. `TypeType` boxed each
list and non-`null` modifier, and every clone of a `TypeType` copied
these boxes. Each field path was a new `Arc`. A field sub-executor also
looked up the field in the schema a second time. The generated
resolvers then copied the executor twice for each field.

## What changed

`TypeType` is now a `Copy` view of a named type and a slice of
modifiers borrowed from the schema. A `FieldPath` borrows the path of
its parent executor. An `OwnedExecutor` stores its response names,
because it has no parent to borrow from. `field_sub_executor()` takes
the field type from the caller. The generated resolvers call
`resolve()` and `resolve_async()` on the executor from
`replaced_context()`. `resolve_with_ctx()` copied the executor once
more. The unused methods of `OwnedExecutor` are gone.

A synchronous execution of 1000 objects with 6 fields each now makes
11,063 allocations instead of 35,075. On the benchmark operations,
synchronous execution takes 7 to 41% less time, and asynchronous
execution takes 4 to 23% less time.

## Testing

The unit, integration, subscription, codegen, and Book tests pass
without changes.
@LegNeato
Store response objects in a Vec with ArcStr names
f10ed55 
## Why

Each resolved field allocated a `String` for its response name. The
asynchronous executor allocated the name twice. `Object` also hashed
each name with SipHash up to three times per field. It hashed the name
to find an existing field and to insert the new one.

## What changed

`Object` stores its fields in a `Vec` in insertion order. A lookup
compares the names one by one. For the small field counts of GraphQL
objects, this is faster than hashing. Above 16 fields, `Object` builds
a hash index of the names, so a selection set with thousands of aliases
cannot make execution quadratic. A `Box` keeps the index out of
`Value`, so `Value` stays at 32 bytes. The field names are `ArcStr`. A
field without an alias reuses the `ArcStr` name from the schema, so its
response name needs no allocation. The logic that merges fields with
the same response name moved from the executor into `Object`.

A synchronous execution of 1000 objects with 6 fields each now makes
4061 allocations instead of 11,063. On the benchmark operations,
synchronous execution takes 4 to 44% less time, and asynchronous
execution takes 4 to 39% less time.

## Testing

New tests cover adding, merging, and comparing object fields, objects
with an index, and the insertion order.
@LegNeato
Look up fragments, arguments, and field types without SipHash
50c5f57 
## Why

The executor hashed names with SipHash on hot paths. Each fragment
spread looked up its fragment in a `HashMap`. Each field with arguments
built an `IndexMap` of the arguments and hashed every argument name.
Each field also hashed the name of its type to find the type in the
schema. The validation rules hashed the names of the document with
SipHash too.

## What changed

The fragments of a document are in a hash map with the randomly seeded
`foldhash`. It resists hash flooding and hashes short names faster than
SipHash. The hash maps of the parser and the validation rules also use
`foldhash`. The arguments of a field are in a `VecMap`, and a lookup
compares the few argument names one by one. `SchemaType` stores its
types in an `IndexMap`, and each field of an object or interface stores
the index of its type. The executor finds the type of a field by this
index.

On the benchmark operations, synchronous execution takes 5 to 17% less
time, and asynchronous execution takes 2 to 18% less time.

## Testing

The unit, integration, codegen, and Book tests pass without changes.
@LegNeato
Poll async fields and list items once in place
b6f231d 
## Why

Asynchronous execution pushed every field and every list item into a
`FuturesOrdered` set. Each push allocated a task, and each poll paid
for atomic waker operations. Most futures complete on their first poll,
so this cost bought nothing. The future of
`GraphQLValueAsync::resolve_field_async()` borrowed its arguments and
its executor, so the executor kept them in an outer future of its own.
The executor also added a `__typename` field to the object before the
pending fields, so `__typename` could appear out of order.

## What changed

`resolve_field_async()` and the generated `AsyncField::call()` take the
`Arguments` and the `Executor` by value, so the resolver future owns
them. `Executor` is now `Copy`, because all its fields are shared
references or `Copy` values. The generated resolver extracts its
arguments inside its future.

The executor polls the future of a field or a list item once when it
creates the future. A completed field merges into the object, or waits
in a queue behind a pending field. A `__typename` field takes its place
in the queue too. Only pending futures go to a `FuturesUnordered` set,
and the queue keeps the order of the fields and items. A `null` item of
a non-`null` list stops the resolution of the remaining items, as in
synchronous execution. One function now completes field results for
both synchronous and asynchronous execution.

Asynchronous execution of a flat list of 1000 objects now makes 19,067
allocations instead of 27,069. On the benchmark operations except
introspection, asynchronous execution takes 6 to 39% less time.
Synchronous execution and introspection do not change.

## Testing

New tests check the order of fields around a pending field, the order
of pending and ready list items, and the `null` list from a failing
ready item and a failing pending item. The manual implementations in
the tests use the new signature.
@LegNeato
Resolve synchronous fields without futures in async execution
a53f880 
## Why

Asynchronous execution created a future for every field, even if the
resolver of the field and all resolvers below it were synchronous. Each
such field paid for a boxed resolver future.

## What changed

The macros mark the fields without an `async` resolver with the new
`Field::synchronous()` method. `RootNode` finds the types that resolve
without awaiting when it builds the schema. Recursive types form
cycles. The search therefore starts with all types as candidates and
removes the candidates with an asynchronous dependency until no
candidate changes. An interface field is synchronous if it is
synchronous in all implementers.

`Executor::resolve_async()` calls `GraphQLValue::resolve()` for values
of synchronous types. The asynchronous executor resolves a synchronous
field of a synchronous type in place with
`GraphQLValue::resolve_field()`. The Book explains which fields resolve
without futures.

Asynchronous execution with synchronous resolvers now makes as many
allocations as synchronous execution, and it runs as fast. A flat list
of 1000 objects makes 4060 allocations instead of 19,067. On the
benchmark operations except introspection, asynchronous execution with
synchronous resolvers takes 13 to 67% less time. With `async fn`
resolvers, scalars and enums resolve without futures, and execution
takes up to 8% less time.

## Testing

New tests cover the detection of synchronous objects, interfaces,
unions, cycles, and introspection types. Executor tests check that
marked fields and synchronous types use the synchronous resolvers, and
that other fields use the asynchronous resolvers.
@LegNeato LegNeato mentioned this pull request Nov 1, 2026
Open

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@LegNeato