Use interface rather than closure in *ctx to remove memory allocation

[YangKeao]

Enhancement

Using function pointer (actually a closure of struct method) will generate unexpected memory allocation, and harm the speed. Here is a little example to show the mechanism:

package main

type NoAlloc struct{ count int}

func (n *NoAlloc) fn() { n.count += 1 }

type iNoAlloc interface{ fn() }

func (n *NoAlloc) Fast() iNoAlloc {
    return n
}

func (n *NoAlloc) Slow() func() {
    return n.fn
}

func (n *NoAlloc) AlsoSlow() func() {
    return func() {
        n.fn()
    }
}

func main() {
	
}

You can explore these codes on https://godbolt.org/z/r19b1fz1c. You can find that the func (n *NoAlloc) Slow() will call runtime.newobject. Now .ErrCtx() uses the similar pattern, and will make the HandleError very slow. We can solve it by passing the interface.

[siddontang]

except HandleError in your PR, which other places or allocation should we use this way instead? can you also list them so others can contribute?

btw, in this #49280, can you show a detailed profile or others to show that the unnecessary allocation is avoided or the gc has less work or the performance increased in some benchmarks?

[YangKeao]

except HandleError in your PR, which other places or allocation should we use this way instead? can you also list them so others can contribute?

Converting a struct method to raw function type, and returning it out will always make an avoidable heap allocation. It can be easily optimized by using an interface. However, I'm not sure whether this optimization is valuable for most scenarios.

For HandleError it's valuable because HandleError is used everywhere and is called really frequently. For example, in (*Index).GenIndexKey, it's called per rows. I'm reported that the HandleError can take nearly 20% or more in (*Index).GenIndexKey without optimization, which is really unexpected.

But for other scenarios, it's hard to say.

To avoid similar issues in the future, we can analyze the cases in which a struct method is assigned to a func type. Not all of them need to be modified (e.g. some are not escaped, some are not sensitive to a little allocation ...), so they need to be handled case by case.

btw, in this #49280, can you show a detailed profile or others to show that the unnecessary allocation is avoided or the gc has less work or the performance increased in some benchmarks?

Nice suggestion. I attach the profile flamegraph of BenchmarkErrCtx in #49280 (comment). The change of the profile is quite significant.