Thank you for the reply. > The optimization you are talking about is escape analysis.
I was trying to point not the escape analysis itself, but the ability of the compiler to construct stack-based slice for the variadic arguments instead of heap-based slices (like it does with the interfaces). I mean, seems like that there no reason to allocate slice for passing N arguments even for an interface method call? Sergey. On Mon, 11/12/18, fff Nov 12, 2018 at 10:52:07AM -0800, Ian Lance Taylor wrote: > On Mon, Nov 12, 2018 at 4:24 AM, Sergey Kamardin <gob...@gmail.com> wrote: > > > > Also, I may assume that this because the compiler does not knows exactly > > which function it will call in a runtime. > > Most likely, yes. > > > Am I understand it right and are there any plans for preparing such > > optimizations? > > The optimization you are talking about is escape analysis. It's very > hard to do escape analysis across an interface boundary, where you > don't know what the method does. In cases involving plugins and > shared libraries, it is completely impossible to know what the method > does. I'm not aware of any plans to extend escape analysis across > calls to methods of interface values. > > It's true that in an example like yours the compiler knows the dynamic > type stored in the interface. But such examples are relatively > uncommon in Go code, so it's not clear that it's worth the extra time > required in the compiler to look for them. > > 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.
