reflect: Call is slow

[bradfitz]

reflect.Value.Call is pretty slow.

In addition to always allocating a slice for its []reflect.Value result parameters, it
also does a lot of prep work on each call.

It would be nice to both avoid that allocation and also do the setup checks just once.

Maybe a new method to return some sort of 'Caller' type that makes repeated Calls
faster, with less paranoia and no allocation.

Or just speed up the checks and make a new Call method that also accepts a slice for the
result values.

[bradfitz]

Looking at some internal fleet-wide CPU usage, I see reflect.Value.Call and reflect.Value.call show up pretty high in the list.

It might be time to optimize this.

In Go 1.8, there's now precedent in the reflect package for returning a worker func (reflect.Swapper) after doing the validation only once.

Investigate the top 2014 comment's Caller idea, and see how much CPU it can save.

/cc @dsnet

[aclements]

Maybe a new method to return some sort of 'Caller' type that makes repeated Calls faster, with less paranoia and no allocation.

Value.Interface() sort of does this, but you have to call the result like a real function, not using Value.Call(). If you can fit code into using Value.Interface(), then there's no allocation overhead (unless the frame pool is empty) and no validation. The compiler constructs the arguments frame and interprets the result frame and reflect just has to do some memory copying. (That said, it still does two copies of both the arguments and the results. I feel like it should be possible to get that down to one.)

[bruth]

For some concrete numbers, as of 1.9 on darwin/amd64, reflect.Value.Call is ~65-80x slower than other invocation types. Gist of benchmark code.

BenchmarkReflectMethodCall-4         	10000000	       144 ns/op
BenchmarkReflectOnceMethodCall-4     	10000000	       138 ns/op
BenchmarkStructMethodCall-4          	1000000000	         2.20 ns/op
BenchmarkInterfaceMethodCall-4       	1000000000	         2.14 ns/op
BenchmarkTypeSwitchMethodCall-4      	2000000000	         1.88 ns/op
BenchmarkTypeAssertionMethodCall-4   	2000000000	         1.83 ns/op

[patricksuo]

Caching function layout in a Caller reduce 50% reflect call overhead. https://gist.github.com/sillyousu/606e4874839456cc02335bd1c5045f27

update @bruth 's benchmark:

BenchmarkReflectCaller-8                20000000                64.6 ns/op
BenchmarkReflectMethodCall-8            10000000               135 ns/op
BenchmarkReflectOnceMethodCall-8        10000000               126 ns/op
BenchmarkStructMethodCall-8             2000000000               1.67 ns/op
BenchmarkInterfaceMethodCall-8          1000000000               2.41 ns/op
BenchmarkTypeSwitchMethodCall-8         2000000000               1.23 ns/op
BenchmarkTypeAssertionMethodCall-8      2000000000               1.42 ns/op

[dongweigogo]

It seems that java sets a buffer slice to avoid this problem.

[gopherbot]

Change https://golang.org/cl/166462 mentions this issue: reflect: make all flag.mustBe* methods inlinable

[gopherbot]

Change https://golang.org/cl/281252 mentions this issue: reflect: cache IsVariadic calls in Call

[mvdan]

Now that we have #49340, which is a reasonable proposal which is just waiting for a prototype, should we close this issue as a duplicate? Is there any other part of Call which is slower than it needs to be besides the allocation for the results slice?

[mitar]

I updated benchmark by @bruth here and these are results on my machine:

BenchmarkReflectMethodByNameInterface-8   	 3859410	       317.2 ns/op
BenchmarkReflectMethodByName-8            	 5119252	       237.1 ns/op
BenchmarkReflectMethodCall-8              	 8402196	       129.5 ns/op
BenchmarkReflectOnceMethodCall-8          	 9686301	       131.1 ns/op
BenchmarkReflectCallInterface-8           	516733941	         2.164 ns/op
BenchmarkStructMethodCall-8               	472757470	         2.524 ns/op
BenchmarkInterfaceMethodCall-8            	544497948	         2.027 ns/op
BenchmarkTypeSwitchMethodCall-8           	437183308	         2.694 ns/op
BenchmarkTypeAssertionMethodCall-8        	428367258	         2.714 ns/op

I added method invocation of using MethodByName and then of calling .Call directly or of first type-casting through .Interface().(func()). I also added .Interface().(func()) on the method pointer itself. What is interesting to me:

• BenchmarkInterfaceMethodCall (calling a method on the interface value) is faster than BenchmarkStructMethodCall (calling a method on a struct pointer). That is a surprise.
• Type-casting through .Interface().(func()) removes overhead for method pointer, but adds overhead when method is obtained using MethodByName. It is even faster to call .Call on the method from MethodByName than when type-casting it. That is the biggest surprise to me. Doing:

	s := reflect.ValueOf(v)
	f := s.MethodByName("Inc").Interface().(func())
	for k := 0; k < n; k++ {
		f()
	}

I would expect and assume that f would behave and be close to performance of a regular function call. Especially as it looks like a regular function value.

So I think there are definitely some improvements needed here.