Surprised recent versions 1.18+ didn't see a jump in improvement, but might explain sumloop improvement for 1.19 I checked, they use switch on opcodes in vm.go

Surprised recent versions 1.18+ didn't see a jump in improvement, but might explain sumloop improvement for 1.19 I checked, they use switch on opcodes in vm.go. So would expect a recent improvement, but probably only <5%, & I didn't look close enough to see if awk is one of those languages where instruction dispatch matters less (like how APL tends to avoid issues since array ops avoid having dispatch in tight loops, or how Python avoids instruction dispatch overhead when using numpy) Indeed, they have a comment saying array of functions is faster for older versions of go: https://github.com/benhoyt/goawk/blob/158232a76856e12d680a53c0b3ab7666bf2c3c3a/interp/vm.go#L19 https://github.com/benhoyt/goawk/blob/158232a76856e12d680a53... For VMs Go had a problem for large switch statements: it would always use binary search instead of a jump table. This caused gopher-lua & go-lua to both take the route of having an array of functions which they call on to dispatch instead A couple years ago this was fixed: https://go-review.googlesource.com/c/go/+/357330 https://go-review.googlesource.com/c/go/+/357330 I measured a small perf improvement switching gopher-lua to switch: https://github.com/yuin/gopher-lua/pull/479 https://github.com/yuin/gopher-lua/pull/479 edit: looking closer, not sure `compiler.CallBuiltin` is doing them a favor anymore. They seem to have a lot of double dispatch operations (like `compiler.AugAssignField`) which would be less impactful with binary search switch