[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Groovy 3 release

> On 27 May 2018, at 20.25, Jesper Steen Møller <jesper@xxxxxxxxxxxxx> wrote:
> On 27 May 2018, at 14.44, Daniel.Sun <sunlan@xxxxxxxxxx> wrote:
>> Native lambda is only available on master branch, and it is only be enabled
>> under static compilation.
> I had a chance to examine the current implementation. It uses a LambdaMetafactory to bootstrap (i.e. generate inner class) access to the doCall of the generated lambda/closure object. That means TWO classes per lambda definition (in use), and two objects generated at every lambda use. I haven't made any benchmarks, but we should be able to do better:
> 1) Don't distinguish between lambdas and closures.
> 2) If the closure's instantiation is targeting a functional interface, add the expected identified functional interface to the closure class, and implement that in the closure class (bridging the single interface method into the doClass) call.
> 3) If using compilestatic, we don't need any type conversions to match the callee.

4) Added bonus: Even if using dynamic, sometimes we may use our "invested" bridge method so we could avoid creating a proxy.
After all, even a lot of dynamic Groovy ends up calling something which is well known in advance.