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/