-
Notifications
You must be signed in to change notification settings - Fork 17.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: reflect: add allocation-free variant of Value.Call #43732
Comments
I don't mind the idea but I'm not fond of the name. Can we do better than |
Change https://golang.org/cl/284222 mentions this issue: |
Using this benchmark and CL/284222, we achieve a runtime reduction of 1.5x:
|
Closing as duplicate of #49340 (yes, it was filed second, but we ended up with it in the active column first). |
At present,
Value.Call
for any function with any return arguments is slow because it needs to:[]Value
for the return Values themselvesThis is unfortunate since calling a function that returns any arguments is likely the common case. The aforementioned allocations cannot be eliminated because the current API
Value.Call
pretty much requires that the implementation be responsible for allocating the return arguments.I propose a new
CallWith
(or any other suggested name) method with the modified signature:where:
in
argument is identical to that forCall
out
argument must be a slice wherelen(out) == v.NumOut()
.out[n]
is a valid, settable value wherev.Out(n).AssignableTo(out[n].Type())
, thenCallWith
uses the existing value to store the output (withValue.Set
).CallWith
allocates new underlying storage for a newreflect.Value
and stores that intoout[n]
.With this API, I believe it is theoretically possible to have an allocation-free version of
Value.Call
.The description above only proposes
CallWith
as an optimized version ofCall
. You can imagine aCallSliceWith
as an optimized version ofCallSlice
.\cc @mvdan @rogpeppe
The text was updated successfully, but these errors were encountered: