Hi Jochen,
> but this means we will have to manually update the list for java.lang,
> java.util, java.io and java.net
In order to avoid updating the list manually, I tried to find the way
to get the list via reflection or classloader but failed...
However, even if we add this check to
?
>
> Cheers,
> mg
>
>
> Ursprüngliche Nachricht
> Von: Cédric Champeau
> Datum: 24.05.18 08:30 (GMT+01:00)
> An: dev@groovy.apache.org
> Betreff: Performance of the compiler
>
> Hi folks,
>
> I just wanted to share the result of prof
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 a
écrit :
> Would the test performance be improved if @CompileStatic were used? I
> think gradle uses Spock, and last time
Betreff: Performance of the compiler
Hi folks,
I just wanted to share the result of profiling the performance of the compiler
on "real world" classes, namely compiling the tests of Gradle. We have a lot of
tests, so compilation times becomes really a pain point, so I have checked
wher
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 wrote:
>
>
> Am 25.05.2018 um 1
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 insta
FWIW, I tried with compileOptions.optimizationOptions.put("asmResolving",
true)
and it doesn't improve much the situation. Sometimes it's even slower. I
didn't investigate why.
Le ven. 25 mai 2018 à 12:51, Daniel.Sun a écrit :
> Hi Cédric,
>
> I am not going to cache ClassNode instance(jus
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 b
>
> > JPMS would naturally make complicate things further, but again, ECJ has
> cracked this, too.
> >
> > -Jesper
> >
> >> On 24 May 2018, at 08.30, Cédric Champeau wrote:
> >>
> >> Hi folks,
> >>
> >> I just wanted to sh
er
>
>> On 24 May 2018, at 08.30, Cédric Champeau wrote:
>>
>> Hi folks,
>>
>> I just wanted to share the result of profiling the performance of the
>> compiler on "real world" classes, namely compiling the tests of Gradle. We
>> have a l
Be warned that caching may prove to be complicated: what if a class in the
same compile unit is named `List`, or a class in the same package? This is
one of the reasons the lookup is not cached for this.
Le ven. 25 mai 2018 à 10:17, Daniel.Sun a écrit :
> I am going to cache the class names of d
I am going to cache the class names of default imported packages, e.g.
`List`, `ArrayList`, `Map`, `HashMap`, etc.
And try to find the name of ClassNode instance in the class names cache, if
not found, `return false`(add the check at the line[1]). The polished logic
can avoid unnecessary resolving
gt; On 24 May 2018, at 08.30, Cédric Champeau wrote:
>
> Hi folks,
>
> I just wanted to share the result of profiling the performance of the
> compiler on "real world" classes, namely compiling the tests of Gradle. We
> have a lot of tests, so compilation times bec
Hi folks,
I just wanted to share the result of profiling the performance of the
compiler on "real world" classes, namely compiling the tests of Gradle. We
have a lot of tests, so compilation times becomes really a pain point, so I
have checked where we spend time. I have attached the
14 matches
Mail list logo
