reflect: Value.Seq2 on a map value allocates more than Value.MapRange

[mvdan]

Full details over at https://cue.gerrithub.io/c/cue-lang/cue/+/1231138. In summary, a diff like

-			iter := val.MapRange()
-			for iter.Next() {
-				k, val := iter.Key(), iter.Value()
+			for k, val := range val.Seq2() {

is causing an increase in allocs:

                    │     old      │                new                 │
                    │     B/op     │     B/op      vs base              │
        VetBuiltins   136.0Mi ± 0%   137.5Mi ± 0%  +1.12% (p=0.000 n=8)
    
                    │     old     │                new                │
                    │  allocs/op  │  allocs/op   vs base              │
        VetBuiltins   1.264M ± 0%   1.364M ± 0%  +7.91% (p=0.000 n=8)

which doesn't make sense to me, and sounds like some sort of reflect or compiler bug.

I got these numbers with go version go1.27-devel_a430bc1bd7 2026-02-10 21:27:59 -0800 linux/amd64, but I'm sure this also reproduces on 1.26.0, as I originally discovered this issue weeks ago and worked around it in https://cue.gerrithub.io/c/cue-lang/cue/+/1229423.

Note that #76357 is related but not a duplicate; that is about a use case where new API is probably needed to be efficient for arrays and slices. This issue should not require new API at all.

[mvdan]

The Gerrit patch above should be clear enough in terms of reproducing this issue. Let me know if you have any issues seeing the same numbers that I see. I hope that the problem is obvious enough to someone well versed in either reflect or the toolchain; at least from looking at pprof, I'm stumped beyond "maybe Seq2 is causing one of the parameters to escape to the heap".

[mvdan]

I also wonder if it's the use of an iterator which causes the added allocs. I would hope that the compiler is clever enough to avoid that sort of overhead in most cases. I don't think our code here is particularly complex.

[gabyhelp]

Related Issues

• reflect: Value.Seq panicking on iter.Seq2 #71913 (closed)
• proposal: reflect: add reflect.Value.Elems for slices, arrays, and strings #76357
• reflect: map iteration does unnecessary excessive allocation for non-pointer types #32424 (closed)
• reflect: add a range like interface for Value #11104 (closed)
• maps: Equal should not allocate on the heap #65329 (closed)
• reflect: add Type.CanSeq/CanSeq2 and Value.Seq/Seq2 methods #66056 (closed)
• reflect: add MapIter.Reset #46293 (closed)
• reflect: Value.Seq iteration value types not matching the type of given int types #71905 (closed)

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

[adonovan]

There are two heap allocations in the range val.Seq2() loop. The first is the state variable used to communicate the continuation from the loop body's yield function to the range statement. In all non-inlined range-over-func loops it escapes to the heap. The second is the closure for the yield function, which again escapes in non-inlined loops.

Replacing Seq2 by the following code (which is valid only for maps, of course) causes both allocations to melt away:

func (v Value) Seq2() iter.Seq2[Value, Value] {
	return func(yield func(Value, Value) bool) {
		i := v.MapRange()
		for i.Next() {
			if !yield(i.Key(), i.Value()) {
				return
			}
		}
	}
}

Adding //go:noinline to this Seq2 negates the benefit. The problem is that the complex definition of Seq2 defeats inlining, and escape analysis is synergistic with inlining, so the state variable and closure have to be heap allocated.

[mehrdadbn9]

I'd like to investigate this performance issue with Value.Seq2 allocations. I can benchmark and propose a fix. Please assign if appropriate.

[mvdan]

@adonovan what is really interesting is that the patch shown above touches code which does not run at all with the provided benchmark. If you add a debug println there, it never runs, even though fromGoValue is executed ~100k times.

So this is not that the direct use of reflect.Value.Seq2 is allocating, but rather that its use is somehow affecting how the rest of the function is compiled, and perhaps whether some of its variables or parameters are escaping.

[mknyszek]

CC @golang/runtime