Benchmarking Go 1.27's encoding/json: The `any` Trap

03 July 2026

Background

I’m developing software that needs strong JSON library performance, especially on the decoding side.

encoding/json/v2 has been experimental in Go for almost a year. It started from this issue. Starting in Go 1.25, it became part of the experimental feature set. In Go 1.27 (coming this August), v2 becomes the default backend for encoding/json.

Questions in my mind

• Is v2 faster? This is easy to answer.
• Is the Go 1.27 encoding/json compatibility path faster? Considering the breaking changes in v2, and considering Go’s compatibility promise, will compatibility affect performance?
• How does it compare to other well-known libraries, such as goccy/go-json?

Benchmark & Results

I asked GPT-5.5 to run the benchmark. The test uses Go 1.27rc1 and runs on my MacBook Air M2 with 24 GB of memory. The test data is NDJSON with 100,000 entries. A sample from the data looks like this:

{"type":"request","connection_id":996,"timestamp":"2026-07-01T00:42:05.503678Z","log_type":"DownstreamStart","http":{"version":"HTTP/1.1","method":"GET","scheme":"http","authority":"testhttp:8080","path":"/api/v1/resource/4"},"headers":{"x-api-key":["rqt_api_dummy-apikey-local"],"x-forwarded-host":["testhttp:8080"],"x-forwarded-port":["8080"],"x-forwarded-proto":["http"],"x-forwarded-scheme":["http"],"x-real-ip":["172.18.0.1"]},"body":{}}

The benchmark runs four cases:

• encoding/json/v2 native: directly import v2 and run decode and encode.
• encoding/json: in Go 1.27rc1, this is backed by the v2 implementation with compatibility support. That means v2 can make breaking changes, but as long as you are not using the v2 import path, behavior should remain compatible with v1.
• encoding/json with GOEXPERIMENT=nojsonv2: this is a build-time Go experiment setting that makes encoding/json use the legacy v1 implementation.
• goccy/go-json: a third-party library that does not rely on encoding/json. It is included for comparison.

Decode results

Encode results

At first glance, when using encoding/json with the default jsonv2 backend, decoding is slower than legacy v1 in this benchmark. It is only about 80% of legacy v1 throughput. For encoding, the compatibility path is modestly faster than v1 in this run.

From the Go 1.27 release notes:

Marshal performance is broadly at parity with the previous implementation, while unmarshal performance is significantly faster.

That does not match this benchmark. What happened?

Why?

So I asked GPT-5.5 to analyze why this happens. This is what it found.

We start from profiling:

Pay attention to the extra reflection cost. This is one of the main places where the additional decode time is spent.

The extra decode cost mostly comes from the compatibility path falling out of the optimized any decoder and into generic reflection-heavy decoding.

Native v2 has an optimized any path, but it only applies when duplicate-name compatibility is disabled:

// encoding/json/v2/arshal_default.go
if optimizeCommon && t == anyType && !uo.Flags.Get(jsonflags.AllowDuplicateNames|jsonflags.FormatTag) && (uo.Unmarshalers == nil || !uo.Unmarshalers.(*Unmarshalers).fromAny) {
    v, err := unmarshalValueAny(dec, uo)
    if v != nil {
        va.Set(reflect.ValueOf(v))
    }
    return err
}

The encoding/json v1 compatibility options enable duplicate names:

// encoding/json/internal/jsonflags/flags.go
DefaultV1Flags = 0 |
    AllowDuplicateNames |
    AllowInvalidUTF8 |
    EscapeForHTML |
    EscapeForJS |
    PreserveRawStrings |
    Deterministic |
    FormatNilMapAsNull |
    FormatNilSliceAsNull |
    MatchCaseInsensitiveNames |
    CallMethodsWithLegacySemantics |
    FormatByteArrayAsArray |
    FormatBytesWithLegacySemantics |
    FormatDurationAsNano |
    MatchCaseSensitiveDelimiter |
    MergeWithLegacySemantics |
    OmitEmptyWithLegacySemantics |
    ParseBytesWithLooseRFC4648 |
    ParseTimeWithLooseRFC3339 |
    ReportErrorsWithLegacySemantics |
    StringifyWithLegacySemantics |
    UnmarshalArrayFromAnyLength

Because AllowDuplicateNames is true, the optimized v2 any fast path is skipped. The decoder goes through:

• encoding/json/v2.makeInterfaceArshaler.func2
• encoding/json/v2.makeMapArshaler.func3
• reflect.New
• reflect.Value.Set
• reflect.Value.assignTo
• reflect.Value.SetMapIndex
• arshaler lookup via internal/sync.HashTrieMap.Load

Legacy v1 has a direct any path for this exact benchmark shape:

// encoding/json/decode.go
// The xxxInterface routines build up a value to be stored
// in an empty interface. They are not strictly necessary,
// but they avoid the weight of reflection in this common case.
func (d *decodeState) valueInterface() (val any)
func (d *decodeState) objectInterface() map[string]any

This benchmark decodes every record into any, so that difference dominates.

So decoding into any through the compatibility path is the culprit in this benchmark. Let’s ask GPT-5.5 to run another test without decoding into any:

This time we see the decode performance gain.

Can we use the fast path?

As we saw above, we cannot use the fast path because of the condition below:

if optimizeCommon && t == anyType && !uo.Flags.Get(jsonflags.AllowDuplicateNames) && uo.Format == "" && (uo.Unmarshalers == nil || !uo.Unmarshalers.(*Unmarshalers).fromAny)

Specifically, AllowDuplicateNames is true by default. It’s tempting to remove it from the condition. However, the comment above this condition clearly says:

// Optimize for the any type if there are no special options.
// We do not care about stringified numbers since JSON strings
// are always unmarshaled into an any value as Go strings.
// Duplicate name check must be enforced since unmarshalValueAny
// does not implement merge semantics.

Imagine the case below:

var v any = map[string]any{
    "x": map[string]any{"old": float64(1)},
}
json.Unmarshal([]byte(`{"x":{"new":2}}`), &v)

In this case, we cannot simply remove the AllowDuplicateNames check because of the behavior.

Conclusions

At the start, GPT-5.5 chose any because the NDJSON data has mixed event shapes. After the analysis, we noticed that decoding into any through the compatibility route uses reflection-heavy generic decoding, which adds overhead. So we accidentally found an edge case where the v2-backed compatibility path can be slower than v1.

In another run without decoding into any, we saw the struct decode performance gains promised by v2.

In hindsight, you can’t blame GPT-5.5 for being lazy. Sometimes, when facing mixed or complex data types, you tend to use any. Now we know the cost.

The software I mentioned at the beginning of the post will be released soon as part of Reqfleet, the load testing service.

Related Posts

• 29 Jun 2026 » Weekly Reading #26
• 21 Jun 2026 » Weekly Reading #25
• 13 Jun 2026 » Weekly Reading #24