2 ms·
That will still evaluate the cond in all cases. Passing a func will make it lazy but might have performance implications (I’d have to test it).
by kasey_junk 8y ago
That will still evaluate the cond in all cases. Passing a func will make it lazy but might have performance implications (I’d have to test it).
- crawshaw 8y agoIt won't, because of inlining and dead code removal. (At least, it didn't back around Go 1.11 when I last tested this.)
- kasey_junk 8y agoMaybe if the thing that is generating the cond at the call location is inline-able, but not if it's doing an expensive operation. https://play.golang.org/p/Ts6QqRrWwuQ https://play.golang.org/p/Ts6QqRrWwuQ I couldn't get that to not trigger the lock. [later] I could get it to remove it if you pass in a func instead.
- chronial 8y agoYour Cond() has a side-effect. It can never be optimized away.
- kasey_junk 8y agoCorrect. Which is one of the differences between this approach & macros. Though the lazy approach appears to work.
- chronial 8y agoIf you do Assert(ExpensiveOp()), removing all of it is only a valid optimization if ExpensiveOp() is 100% side-effect free. But even when that is the case, the compiler won't inline ExpensiveOp() and go through the effort of proving that it's side effect free if it's sufficiently complex.