Thanx for all the responses but they are not what I need. What I want is the mental model to look at the cost of closures rather than solving a particular performance problem. Pointers to the specific ways closures are implemented plus the basics of usual go compiler optimisations (gc rather than gcc) would be more helpful. Tickets or outlines for future plans for optimisation would be nice too.
A benchmark does not give me that. Benchmarks can at most do comparison of two or more particular code bases when run with a particular toolchain (and on a particular processor). The whole reason I had any benchmark in the initial question is to prove I am willing to walk the walk when it comes to comparing implementations. Jason, thanx for bringing up the work of Prashant who is a former colleague though this particular presentation is a bit dated as it was done 9 years ago. Note that it also does measurements at runtime - so the code has already been written and deployed to production. I am not expecting magic bullets but rules of thumb. I agree that when you need exact results and actually doing the optimisation work you need to find the hot spots and then do benchmarks. I also don't buy the argument that any efforts for such rules of thumb would be premature optimisations. We tend to gravitate to using O(ln(x)) algorithms rather than O(n2) even at the moment we write the initial code. Anyway - I get I'll need to do more homework and delve in: - src/cmd/compile/internal/walk/closure.go - src/cmd/compile/internal/inline/inl.go - src/cmd/compile/internal/escape/expr.go Kind regards: al_shopov -- 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/CAP6f5Mnvu-2M1XFVXHTWaD1FvX5jjpoBB6KUeA3neLk5dFnX%3DA%40mail.gmail.com.
