Yes. Fundamentally, I'm asking if step #2 in your calling sequence can be optimized.
1. load a function pointer from the itab 2. call the function pointer. *However, if the function pointer to is empty, just do a NOP here and skip the function-call-dance. This should be possible as the i-tab is created dynamically on first reference, which means that it can know if the function is empty and put NOP indicator in the i-tab instead of the function pointer. *That's the optimization I'm asking about. On Friday, December 1, 2017 at 2:22:24 PM UTC-5, Ian Lance Taylor wrote: > > On Fri, Dec 1, 2017 at 10:42 AM, Ugorji Nwoke <ugo...@gmail.com > <javascript:>> wrote: > > > > 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. > > That does not seem to me to be an accurate description of the current > implementation. Calling a method of an interface is > 1. load a function pointer from the itab > 2. call the function pointer > > > > 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)? > > The itab does not contain code, it just holds function pointers. > > 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.
