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/

Reply via email to