Re: Gradle build updates

[Daniel.Sun]

Amazing! The build of master costs only about 15 min now(about 25 min in the
past).

Cédric, you help us save a lot of time, thanks a lot!

Cheers,
Daniel.Sun



--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: Building Groovy

[MG]

Just came across this as an example where using Groovy 2.4.6 
invokedynamic seems to have been much slower than the older callsite 
caching mechanism: 
https://www.linkedin.com/pulse/how-make-groovy-fast-java-david-e-jones 
(https://dzone.com/articles/how-to-make-groovy-as-fast-as-java)


Quote:
"While Groovy has performance options that allow you to keep your code 
dynamically typed I never had good results with them. For Moqui 
Framework using the Indy compiler and runtime (for Java invokedynamic) 
actually made it significantly slower!
The best option for code that needs to run fast is the @CompileStatic 
annotation. When you apply this annotation you can't use Groovy features 
that depend on dynamic typing, but fortunately most of the more useful 
features still work just fine."


I can totally understand the pull to get rid of large, old code parts - 
but if this holds for more projects, I expect it will not go down well 
with (dynamic) Groovy users...

mg


On 21.11.2017 17:38, Jochen Theodorou wrote:



Am 21.11.2017 um 08:28 schrieb Paul King:
The "double" build is because of indy vs non-indy (one wipes out the 
other) because of some assumptions that keep other parts of the build 
simple. Could no doubt be streamlined given some TLC.


Last I checked there were different performance characteristics 
between indy/non-indy. We haven't gotten around to working out the 
best path forward yet that will give us one set of jars without 
losing performance in some scenarios. Again, just needs some time 
dedicated to it.


I don't see the old callsite caching still working properly in a Java9 
world, so it is time to cut loose


bye Jochen

Re: Extension method upgrades

[Jochen Theodorou]

On 17.12.2017 23:23, Nathan Harvey wrote:
[...]

I am not familiar with the concept of static categories, can you explain the
difference between that and extension methods? I think we should clear up
the terminology.


the idea is basically to have what we have now for extension methods and 
categories, but reduce the scope to a lexical one. And for this there 
have been two ways thought of, where one way is something like an static 
import of the category methods (so there would be an import statement 
for them basically) and the other way is to change the use-command to be 
able to maximally reduce the scope. Of course this means there will be 
no service required. Thus it would not cause the problem you have imho.



My main focus with this post is removing the step of isolating extension
methods to a separate dependency, as this creates numerous problems. One
large one I haven't mentioned yet is the inability to test the methods
within the same project as they are declared, for example. Anyway there are
obviously a number of ways to achieve this.


Would you be fine with a class level annotation?

bye Jochen

Re: Extension method upgrades

[Nathan Harvey]

I think Groovy's extension methods are not more clean than Kotlin's. Having
to isolate them to an external dependency helps consolidate them, I suppose,
but that doesn't change much for readability within usages - you still have
to Ctrl+Click or similar to find out where a method originates. 

I am not familiar with the concept of static categories, can you explain the
difference between that and extension methods? I think we should clear up
the terminology.

My main focus with this post is removing the step of isolating extension
methods to a separate dependency, as this creates numerous problems. One
large one I haven't mentioned yet is the inability to test the methods
within the same project as they are declared, for example. Anyway there are
obviously a number of ways to achieve this.



--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: Gradle build updates

[Cédric Champeau]

Alright folks, I have completed most of what I wanted to do. The
performance of the build is now much better. I have backported everything
to the 2.5 and 2.6 branches, and also updated CI.

> So is it still possible to produce the groovy-all.jar and
groovy-all-sources.jar from the SDK zip?

The "all" sources is still produced. But there's no all jar anymore.

2017-12-13 17:53 GMT+01:00 :

> So is it still possible to produce the groovy-all.jar and
> groovy-all-sources.jar from the SDK zip?
>