Thanks Ian.
This is not so much about de-virtualization. It's about not making a call
to an empty function i.e. I expect that interface calls come down to
1. dereference the pointer to the i-tab,
2. jump to the appropriate function in the i-tab,
3. call that function.
If that function is a no-op, is the runtime smart enough to skip that
function call completely (e.g. replacing the entry in the i-tab with a
NOP)? That way, making an interface call to an empty function becomes just
a dereference+jump, and *not* dereference+jump+(unnecessary)func-call ?
Currently, in my code, within a tight loop, i have a lot of:
for {
if v.HasSeparators() { v.ReadMapElem() }
...
if v.HasSeparators() { v.ReadMapEnd() }
...
}
If the func call is elided, then I will just call the empty function all
the time and remove the if/conditional checks. The code will become:
for {
v.ReadMapElem()
...
v.ReadMapEnd()
...
}
On Friday, December 1, 2017 at 10:18:38 AM UTC-5, Ian Lance Taylor wrote:
>
> On Fri, Dec 1, 2017 at 2:40 AM, Ugorji Nwoke <ugo...@gmail.com
> <javascript:>> wrote:
> >
> > I know that a no-op function call is optimized away, as it is inlined to
> > nothing.
> >
> > However, what about a no-op interface call?
> >
> > See sample code:
> >
> > type I interface { Do(int) }
> > type T1 struct{}
> > func (_ T1) Do(i int) {}
> > func main() {
> > var v I
> > v = T1{}
> > v.Do(1)
> > }
> >
> > Is it safe to assume the following that calling T1.Do(...) via an
> interface
> > costs a dereference + jump (but NO function call overhead)?
> >
> > I currently have code where I do a lot of conditional checks to
> determine
> > whether to make that interface call or not.
> > However, if I know that the no function call overhead is done when the
> > dynamic function is a no-op, then I will just call the interface
> > method all the time, and not try to be smart within code.
> >
> > I tried looking at "go tool compile -S main.go" output, but I still see
> a
> > CALL in there, but don't know whether the linker/compiler/something
> > optimizes this out.
>
> In general, no. The compiler doesn't currently try to figure out the
> dynamic type of an interface (an optimization known as
> devirtualization). An interface method can only be inlined when the
> dynamic type is known.
>
> The cost of calling an empty method is quite low. It's not zero, but
> I am skeptical that the cost of the call is more than the cost of the
> conditional checks you mention.
>
> Ian
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
