groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cédric Champeau <cedric.champ...@gmail.com>
Subject Re: Performance of the compiler
Date Fri, 25 May 2018 13:02:13 GMT
The problem is not the performance of the test, it's the performance of
_compiling_ the test. @CompileStatic wouldn't help there.

Le ven. 25 mai 2018 à 14:24, Thibault Kruse <tibokruse@googlemail.com> a
écrit :

> Would the test performance be improved if @CompileStatic were used? I
> think gradle uses Spock, and last time I checked Spock could not be
> used with @CompileStatic. But Spock could also be removed with some
> effort...
>
> On Fri, May 25, 2018 at 8:52 PM, Jochen Theodorou <blackdrag@gmx.org>
> wrote:
> >
> >
> > Am 25.05.2018 um 12:51 schrieb Daniel.Sun:
> >>
> >> Hi Cédric,
> >>
> >>       I am not going to cache ClassNode instance(just cache class names,
> >> which are `String`), but I want to add a check whether the name of the
> >> ClassNode being resolved is possibly in the default imported packages,
> >> e.g.
> >> If a ClassNode instance's name is `Foobar`(apparently it could not be in
> >> any
> >> default imported packages), then we can `return false` immediately and
> the
> >> further resolving can be eliminated.
> >
> >
> > but this means we will have to manually update the list for java.lang,
> > java.util, java.io and java.net
> >
> > Take for example Module. It is new in Java 9 and is in java.lang. If we
> had
> > this logic already in say Groovy 2.0 I am pretty sure the last versions
> till
> > Groovy 2.3 would not be able to resolve this class anymore then.
> >
> > I think there would be no problem with Java10, but think of Java 11...
> we do
> > not know yet.
> >
> > bye Jochen
>

Mime
View raw message