Performance implications of the lambda draft specification

[Neal Gafter]

An unfortunate consequence of a closures specification/implementation
would be that it is twice as costly to create as an "equivalent"
anonymous inner class, and twice as costly to invoke as an
"equivalent" anonymous inner class.  But that appears to be where the
specification in its current form is taking us.

The performance costs arise from a number of features of the current
specification
(1) The requirement that "this" inside a lambda refers to the lambda itself;
(3) The likelihood of implementing the specification using
MethodHandle for function types;
(2) The desire to support SAM classes; and finally
(4) The lambda conversion as a way of converting a value of function
type to a SAM type.

The creation cost I'm concerned about is double allocation: first
allocating an object of the function type, and then allocating an
object of the SAM type.  The invocation cost I'm concerned about is
double invocation: the client's invocation of the SAM's method, and
then the invocation of the function object inside the
compiler-generated implementation of the SAM.

By contrast, these problems don't arise in BGGA because there is no
function object (or function type) distinct from the SAM, and the
lambda conversion occurs at compile-time (not runtime).

Cheers,
Neal