[java] Improve Java parsing performance #237
Conversation
|
It doesn't seem to outright help with times on CI, but it does on my machine. I think these changes are useful nonetheless. |
|
@vemv Is there an explicit reason why Eastwood runs in each test job and not together with Kondo and others in a dedicated job? EDIT: found the answer. Still, maybe limiting it to a single Java version at least makes sense? |
|
Hi @alexander-yakushev ! Please explain the nature of the changes Thanks - V |
| (.getKind ^Element %))) | ||
| (mapv #(parse-info % root)) | ||
| (filterv #(= klass (:class %))) | ||
| (first)) |
There was a problem hiding this comment.
Because of eagerness, this code invoked parse-info on every element of root even though we only need the first one that matches (= klass (:class %).
| (.getKind ^Element %))) | ||
| (keep #(parse-info % root)) | ||
| (filter #(= klass (:class %))) | ||
| (first)) |
There was a problem hiding this comment.
This is a bit better due to laziness, but it will still realize at least a 32-chunk of parse-infos before doing first on them.
| @@ -476,8 +476,7 @@ | |||
| [ns sym] | |||
| (when-let [ns (find-ns ns)] | |||
| (->> (vals (ns-imports ns)) | |||
| (map #(member-info (-> ^Class % .getName symbol) sym)) | |||
| (filter identity) | |||
| (keep #(member-info (-> ^Class % .getName symbol) sym)) | |||
There was a problem hiding this comment.
This one is minor.
Not necessarily as Eastwood detects Java method deprecations - these vary per JDK Plus, code evaluation can fail for arbitrary reasons - the chosen JDK is an important factor, so more JDKs == more coverage |
|
Thanks much for the changes! Hopefully this will make at least some difference. I'll want to work on #211 sometime in the year. |
I've noticed that most of the time spent during running tests is calling
source-infofrom different places.