I have become quite interested in tail-call optimisation and more distantly in code that assembles trees of closures all tied to the same scope through parameters to reduce stack management for complex but not always predictable input.
As I have learned from some reading, tail call optimisation is a fairly frequently requested feature that is not planned to go into Go 2, so I am just wondering what actually happens when you end functions with a call, especially that shares the same receiver as the calling function. I figure it changes the procedure a little compared to calling before, since the compiler knows no more variables in the caller are going to be changed except the return value. I also figure that it reduces the rate at which the stack expands since the first function does not need to save its state to resume. Does or can it have a performance impact? What I'm thinking is that it works like a trampoline, in that it means the stack doesn't grow so even if you change nothing else when using a recursive algorithm, moving it to tail calls - does it reduce the stack growth rate, and if so, how can this be exploited to reduce overhead? -- 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.
