I was about to do something like that:
var p *P
...
otherpackage.f(func(data []byte) {
a := p.x + p.y * 42 + p.someothercomplicatedstuff
p.g(data, a)
}
(Yeah, I know. I dislike callbacks too, but I'm pretty much stuck in
this particular case since Go doesn't do mutually dependent packages.)
I then realised that I was building a closure on each iteration, and
I wasn't sure if the compiler would be smart enough to lift the creation
of the closure out of a rather complex loop, so I replaced this with :
func (p *P) gprime(data []byte {
a := p.x + p.y * 42 + p.someothercomplicatedstuff
p.g(data, a)
}
...
otherpackage.f(p.gprime)
Now this code was originally in an inner loop, but I've since restructured
it and I can no longer easily profile it. But I'm still curious:
1. is it expected that passing a function obtained from a method
doesn't cons, and is this likely to remain the case in future
versions of the compiler?
2. would the closure in my first code sample cons on every loop
iteration, or would the compiler optimise it away? The loop spans
multiple functions and involves some channel communication, so it's
not entirely trivial to do the lifting.
3. am I worrying too much?
Thanks,
-- Juliusz
--
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.
