You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@beam.apache.org by "Robert Burke (JIRA)" <ji...@apache.org> on 2018/07/11 17:29:00 UTC
[jira] [Created] (BEAM-4765) Use explicit receivers for method
invocations.
Robert Burke created BEAM-4765:
----------------------------------
Summary: Use explicit receivers for method invocations.
Key: BEAM-4765
URL: https://issues.apache.org/jira/browse/BEAM-4765
Project: Beam
Issue Type: Sub-task
Components: sdk-go
Reporter: Robert Burke
Assignee: Robert Burke
Presently we use the "receiverless" variant to reflectively get methods on structs in graph/fn.go, but it's possible to get a version with an explicit receiver as well. Unfortunately due to reflect method invocation overhead, calls to functions sourced this way have significant overhead.
This task represents a TODO in graph/fn.go
I wrote a benchmark (to be submitted) that explores the approaches:
BenchmarkStructMethodCalls/ReflectCallNoReceiver-12 5000000 377 ns/op 56 B/op 3 allocs/op
BenchmarkStructMethodCalls/ReflectCallWithReceiver-12 5000000 297 ns/op 48 B/op 2 allocs/op
BenchmarkStructMethodCalls/DirectWithReceiver-12 300000000 3.58 ns/op 0 B/op 0 allocs/op
BenchmarkStructMethodCalls/TypeAssertedWithReceiver-12 300000000 3.58 ns/op 0 B/op 0 allocs/op
BenchmarkStructMethodCalls/ReflectXCallWithReceiver-12 5000000 345 ns/op 112 B/op 5 allocs/op
BenchmarkStructMethodCalls/ShimedCallWithReceiver-12 20000000 69.3 ns/op 40 B/op 3 allocs/op
BenchmarkStructMethodCalls/ShimedCall1x1-12 100000000 20.7 ns/op 8 B/op 1 allocs/op
Note: Some of these represent the compiler assisting the explicit calls, due to the micro benchmarking: DirectWithReceiver, and TypeAssertedWithReceiver in particular.
ShimedCallWithReceiver represents the "typical" invocation path with a reflectx.Func.Call([]interface{}) invocation, while ShimedCall1x1 is the arity specialized version.
Note: This be a breaking change to anyone using the reflectx & graph packages on structural DoFn outside of the project. However, we don't presently make a stability guarantee on these internal package details, so that's probably OK.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)