encoding/json/v2: marshaling slices of typed structs is 1.5x–2x slower in Go 1.27 vs legacy implementation

[Deleplace]

Go version

go version go1.27.0 linux/amd64

Output of go env in your module/workspace:

GOARCH='amd64'
    GOOS='linux'
    GOVERSION='go1.27.0'
    GOTOOLCHAIN='go1.27.0'
    GOEXPERIMENT=''
    GOAMD64='v1'
    CGO_ENABLED='1'

(Other values redacted)

What did you do?

I read @lemire's tweet "The new Go JSON API: twice as fast, or 1.5x slower?" and replicated the benchmarks on macOS and on Linux.

Using benchstat on Lemire's benchmark output files when marshaling an array of 10,000 small structs:

    # macOS arm64 (Apple M4 Max)
                         │ legacy (nojsonv2) │            Go 1.27 (v1 API)            │            Go 1.27 (v2 API)            │
                         │      sec/op       │    sec/op     vs base                  │    sec/op     vs base                  │
    MarshalRecords (10k)        1.633m ± 1%      2.477m ± 2%   +51.73% (p=0.000 n=8)      2.486m ± 2%   +52.30% (p=0.000 n=8)

A 52% speed regression on MarshalRecords is what Lemire observed and shared.

Note: I used the AI agent Antigravity for the tasks described below.

    git clone https://github.com/lemire/Code-used-on-Daniel-Lemire-s-blog.git repo
    cd repo/2026/08/29
    mkdir -p testdata
    curl -fsSL -o testdata/twitter.json "https://raw.githubusercontent.com/simdjson/simdjson/master/jsonexamples/twitter.json"
    curl -fsSL -o testdata/canada.json "https://raw.githubusercontent.com/miloyip/nativejson-benchmark/master/data/canada.json"
    curl -fsSL -o testdata/citm_catalog.json "https://raw.githubusercontent.com/simdjson/simdjson/master/jsonexamples/citm_catalog.json"

    GOTOOLCHAIN=go1.27.0 ./run.sh

    benchstat results/$(hostname -s)-legacy.txt results/$(hostname -s)-v1v2.txt

What did you see happen?

A 40% regression on my MacBook M4:

               │ Legacy (Base) │       Go 1.27 json          │       Go 1.27 jsonv2        │
               │    sec/op     │    sec/op     vs base       │    sec/op     vs base       │
MarshalRecords     1.728ms     │    2.419ms  +40.04% (p=0.008)│    2.420ms  +40.09% (p=0.008)│

A 102% regression on a Linux VM:

    # Linux x86_64 (Intel Xeon @ 2.20GHz)
                         │ legacy (nojsonv2) │            Go 1.27 (v1 API)            │            Go 1.27 (v2 API)            │
                         │      sec/op       │    sec/op     vs base                  │    sec/op     vs base                  │
    MarshalRecords (10k)        5.826m ± 3%     11.763m ±16%  +101.90% (p=0.000 n=8)     12.062m ± 7%  +107.03% (p=0.000 n=8)

What did you expect to see?

Marshaling a slice of typed structs seems to have regressed significantly in Go 1.27 compared to the legacy implementation (GOEXPERIMENT=nojsonv2).

The new v2 engine emits structured tokens through jsontext.Encoder. For dense struct slices (e.g. 10,000 items of 6 fields), the overhead of per-token state machine, namespace tracking, depth validation, and BeginObject/EndObject transitions, is large.

[gabyhelp]

Related Issues

• encoding/json: skyrocketing memory allocation in encoding when `jsonv2` experiment enabled #75026 (closed)
• encoding/json/v2: performance regression when umarshalling in []any #77642
• encoding/json: Unmarshal into any is slower with jsonv2 compatibility than with nojsonv2 #80270
• encoding/json: performance regression marshaling small values for goexperiment.jsonv2 #74617
• encoding/json: Unmarshal to a typed struct uses 50% more bytes in go 1.21 (and current versions) vs go 1.20 #69828 (closed)
• encoding/json: changes in gotip(1.27) without any changes #79770 (closed)
• encoding/json/v2: Unnecessary allocation marshalling struct with IsZero method and omitzero #80868
• runtime: performance degradation on tip that disappears when traced/profiled #67857
• encoding/json: `format:emitempty` error with v1 `json.Marshal` #80962 (closed)

Related Code Changes

• encoding/json: Improve marshal/encode memory utilization

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[prattmic]

cc @dsnet @neild @ChrisHines

[lemire]

Daniel Lemire, "The new Go JSON API: twice as fast, or 1.5x slower?," in Daniel Lemire's blog, August 29, 2026, https://lemire.me/blog/2026/08/29/the-new-go-json-api-twice-as-fast-or-1-5x-slower/.

[jakebailey]

I spent the weekend screwing around with this and have mailed a stack which appears to recover all of the perf (and then some):

Stage	CL	Time	Change from prior stage	Change from initial v2	Compared with v1
Legacy v1 (nojsonv2)	—	1.659 ms	—	—	baseline
v2	CL 828566	3.094 ms	—	—	86.53% slower
Lazy addressability	CL 828567	3.043 ms	1.67% faster	1.67% faster	83.42% slower
Buffer pointer stores	CL 828568	2.538 ms	16.57% faster	17.97% faster	53.02% slower
go:noinline workaround	CL 828569	2.158 ms	14.98% faster	30.25% faster	30.10% slower
Scalar marshaling	CL 828570	1.594 ms	26.16% faster	48.50% faster	3.94% faster
Map scratch allocation	CL 828571	1.598 ms	statistically unchanged	48.37% faster	3.69% faster

It's all sort of little papercuts, but most of the problem is #81380.

The last CL doesn't help the issue here, but, I did notice it so threw it on top as it helps other benchmarks.

[gopherbot]

Change https://go.dev/cl/828570 mentions this issue: encoding/json/jsontext, encoding/json/v2: optimize scalar marshaling

[gopherbot]

Change https://go.dev/cl/828566 mentions this issue: encoding/json, encoding/json/v2: add record and scalar benchmarks

[gopherbot]

Change https://go.dev/cl/828568 mentions this issue: encoding/json/jsontext, encoding/json/v2: avoid redundant buffer stores

[gopherbot]

Change https://go.dev/cl/828567 mentions this issue: encoding/json/v2: lazily copy unaddressable values

[gopherbot]

Change https://go.dev/cl/828569 mentions this issue: encoding/json/v2: avoid inlining struct arshaler construction