Microbenchmarks are often unrepresentative of real world behaviour. The OP's microbenchmarks found no significant difference, but I think they are very poor examples.
For one, a good compiler might have optimised out the whole loops - although this appears not to have happened here. For another, these are compute-bound functions - each function takes about 12ms to run - so do not measure the cost of call and return from a closure versus a "normal" function. But even with step=int32(500_000_000) I see no difference. More importantly, these functions are so trivial that they almost certainly run entirely in registers. The initial "d := step" line copies the closure variable to a local variable, and I'd say that's highly likely to use a register. However again, changing the loops to use "step" directly doesn't appear to make a difference. You can use godbolt if you want to look at the compiled code, which will answer your questions about inlining. Whether the cost is significant in a particular real-world application is a very different, and much more relevant question; that will be specific to the OP's real-world problem. The only general feedback I can offer is: "I've not heard anybody complain here about the cost of closures in Go". The OP has also identified that if there is a problem, it is likely to be related to garbage collection. Go's GC is continuously improving, and is not a problem for many real-world workloads. If their application really has a critical bottleneck in this area, then maybe a non-GC language would be more suitable. But to me, this sounds like a severe case of premature optimisation. -- 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/4e4206b1-22af-49dd-8d92-e9ee6169fb5cn%40googlegroups.com.
