groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <blackd...@gmx.org>
Subject Re: Performance of resolver
Date Mon, 28 Sep 2015 17:05:55 GMT
Am 28.09.2015 15:01, schrieb C├ędric Champeau:
> Hi guys,
>
> As part of my job at Gradle I recently investigated the performance of
> the ResolveVisitor. As far as I can see, it is still a major hotspot in
> compilation times, especially in the case, like Gradle, where lots of
> default imports are added.
>
> The discussion can be found here:
> https://groups.google.com/d/topic/gradle-dev/nu5FYX83aPw/discussion
>
> It would be interesting to do something on our side, either provide
> hooks or be smarter at resolve time to improve the situation.

Frankly that discussion does not give me much. A cache for multiple 
compilations makes sense in a gradle context but not so much in a 
general groovy context for example. We could provide something for this, 
but frankly, you would "only" have to reuse the ClassNodeResolver. Which 
is also the hook you talk about. Why does it not fit the needs of gradle?

If we really want to improve the situation a lot, then I suggest writing 
out the class resolution rules independent of the implementation and 
work on improving that. I guess 
http://docs.oracle.com/javase/specs/jls/se8/html/jls-6.html#jls-6.5 
describes that.. finding also JEP 215 and bugs like 
https://bugs.openjdk.java.net/browse/JDK-8056066 show that these things 
are far from simple though

And not to forget: we have to resolve more names than Java does as well


bye blackdrag

-- 
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/


Mime
View raw message