I don’t have specific knowledge about how this works - but wouldn’t it be fairly easy to test by having the compiler emit the assembly code?
-- Michael Banzon https://michaelbanzon.com/ > Den 1. dec. 2017 kl. 19.42 skrev Ugorji Nwoke <ugo...@gmail.com>: > > 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 <>> 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 > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- 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.
