Improve: optimize graphql runtime

[n9te9]

What happened?

The transport.Post implementation in the Do method has potential for optimization. Specifically, two areas could improve performance:

1. The Do method frequently converts []byte to string, which incurs additional allocations.
2. graphql.RawParams could benefit from a sync.Pool to reduce allocations and reuse memory.

What did you expect?

Optimizing memory allocation in the Do method should lead to better overall performance for the gqlgen server, especially for high-throughput applications.

Minimal graphql.schema and models to reproduce

I tested using the gqlgen initial schema and an empty slice return for the Todos query, observing allocation patterns during benchmarking.

Versions

• gqlgen version: v0.17.55 (via go run github.com/99designs/gqlgen version)
• Go version: go1.23.2 darwin/amd64

Pull Request

https://github.com/99designs/gqlgen/pull/3373

[n9te9]

@StevenACoffman I took benchmark again, and check the profile. It seems the gqlgen bottle-neck is json decoding below.

I took benchmark using goccy/go-json instead of encoding/json, total memory usage is 1.15% (832 B / 720 B) optimized.

I created PR #3405

[StevenACoffman]

@lkeix the benchmarking is very helpful!

In #2842 it was proposed to allow JSON configuration to be configurable, and several people in the community have warned me against defaulting to using goccy/go-json as in this comment. In #2757 it was suggested to that there are more than one alternative JSON encoding library people might want to use:

Some of these libraries include:

• goccy/go-json
• json-iterator/go
• bytedance/sonic
• segmentio/encoding
• mailru/easyjson
• minio/simdjson-go
• wI2L/jettison
• go-json-experiment/json - Go json/v2 WIP

See related:

• #2757
• #3372
• #2842
• #3161