[go-nuts] Defer performance

If that's your whole program, then, yes, it is normal....

The defer statement is fairly fast, but it's true that it is not as fast as
it could be. There is some discussion of making defer run faster in
https://golang.org/issue/6980 . I also think it might be possible to speed
up the fairly common case of a zero-argument defer by skipping the argument
handling.

Ian

I have taken the practice to doing the defer prior to the lock:

defer mu.Unlock()
mu.Lock()

defer does take time, as you noticed, so if you are going to use defer,
doing it outside of the lock makes the critical section just a smidgen
shorter. Of course, even more efficient is not do a defer at all and just
call Unlock after the region (and every place you can exit).

This re-ordering was suggested by Dmitry Vyukov sometime back.

     -Paul

Changing the order to that, will reduce thread contention, but I don't
think it will make the defer instruction faster. Am I right?

Correct, it does not make defer faster, it only reduces lock contention (by
a small amount). It more acknowledges your point that defer is not free,
which is why deferring the unlock before the lock makes sense.

     -Paul

That approach could cause a problem. If Lock() fails (not sure how) then
the deferred Unlock() will panic or worse it may actually Unlock() the
mutex that another thread may have locked in the mean time introducing an
ugly bug. I'm not sure it's safe to do so, unless I'm missing something.

You should probably have a very strong reason for such an optimization
otherwise it's probably best to live with it and wait for the runtime to
improve the performance of defer.

There is no failure mode that ordering the Lock/Unlock in the
"correct" way would handle but the "incorrect" ordering wouldn't
handle. Lock doesn't return an error, for instance. So I don't agree
with this.

-Caleb

There isn't one today but what if in the future Lock() can panic? I don't
know if that would be acceptable behavior under the 1.x compatibility
rules, but even if it does in 2.x it will make it hard to catch such bugs,
the code will compile just fine but the logic will be wrong.

Yes that would be a behavior change that wouldn't be allowed under the
compatibility rules. Also if Lock could panic, then this code:

mu.Lock()
defer mu.Unlock()

would still crash in that case because it doesn't catch the panic.

Right, but it would not end up unlocking the mutex that may have been
locked by some other goroutine.

If Lock panics then the defer is the least of your concerns.

Fortunately, lock does not panic, it does not return an error. Lock does
what it says it does. I have no interest in coding around a hypothetical
Lock implementation that we don't use.

You are free to order those two statements how ever you want. For an
uncontested lock there is no difference in time. For a contested lock then
doing the defer first will shorten the critical section (not by much, but
by an amount you can measure). You are free to do them in either order,
but both are safe (unless your program has already lost memory safety, at
which point it does not matter) and functionally equivalent.

One measurable cost of these types of micro-optimization is that it
looks odd, so programmers who have not seen the idiom before may
change the statements back to the "right" order unless you add
comments explaining the idiom to every call site. In any case I would
expect truly performance critical critical sections to not use defer
at all.

My advice would be: do it in the natural order unless it measurably
improves performance to do otherwise, and then comment it.

Everything looks odd the first time you see it.

a, b := b, a

t := t


Both of those look odd to a programmer unfamiliar with either concept, the
can probably reason out the first one, the second is a little more
difficult, but the effort of learning why they work is well worth it.

As for lok order, if you don't want to put the defer first, then don't. If
a programmer cannot figure out that

defer mu.Unlock()
mu.Lock()


is functionally equivalent to

mu.Lock()
defer mu.Unlock()


then I don't think the main problem is the order. There is no need to add
extra comments (just like the first two examples given above). Also, if
you don't know why someone would use this order, and you stop and think
about it, hopefully you will come to the conclusion that it shortens the
critical section, also prompting you to think about your critical sections
and making sure they are short. Anyhow, use it or don't. My comment was I
do use it because defers are not free, which supported the OP's point. Ian
has said defers will become less expensive in the future. Great! I will
probably continue to use this order, I like what it implies, but you can
use what order you like. It is one of the great things about freewill ;-)