Comment 1:

I would consider allocating Defers on stack (if number of args is limited)

Comment 2:

If that were possible it would be wonderful. Even for zero arg functions it would be
extremely useful. 
Sent from my iPad

Comment 3:

I am sure it is possible in some [common] cases. It will require some amount CFG
analysis, since apparently (?) one can't do that if defer is executed in a loop.
I guess the function usually needs at least a receiver (mu.Unlock(), f.Close()). There
is no significant difference between 1 and N args.

Comment 4:

I don't think allocating them on the stack will have much benefit
over allocating them on a separate stack.  The key point is to
aggregate the allocations and frees.

Comment 5:

Compiler is able to handle any number of args w/o hardcoding any limits, and I think it
is able to avoid 2 copies of args. However per-M stack of Defers for at most, say, 4
args is much simpler and is able to handle loops, so I agree that it is the way to go.

Comment 6:

Labels changed: added priority-later.

Comment 7:

Labels changed: added performance.

Comment 8:

Labels changed: added go1.1.

Comment 9:

Labels changed: added size-l.

Comment 10:

This issue was closed by revision 0de7161.

Status changed to Fixed.