> On 27 May 2018, at 20.25, Jesper Steen Møller <jes...@selskabet.org> wrote: > > On 27 May 2018, at 14.44, Daniel.Sun <sun...@apache.org> 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. -Jesper
