is it computationally expensive to generate the analysis on the fly?

well, it requires downloading OpenJDK's source code and takes about 30 seconds. This is essentially what clojure-lsp is doing (cc @UKFSJSM38)

ah, i thought you were analyzing the jars directly. that makes sense

The JDKs jars aren't on the classpath

Oh! there's always more to learn...

I could also just include the most popular top 200 classes or so instead of a couple of thousands of them

Then I guess I need to make myself some stats of what those are

which I can do with #C01EF12T49W

tomorrow...

@U04V15CAJ did you try UPX on clj-kondo binary? I'm using for clojure-lsp for linux and mac, it increases slightly the startup time but it's way faster than JVM one (if using native-image)

clojure-lsp binary size is ~120mb something and with upx it's 30mb

for lsp it doesn't matter much but clj-kondo can be invoked quite a few times (e.g. with xargs ) so I don't want to make it slower

guess what, the resource increase didn't come from those transit files at all, it already happened on master. some bisecting to do

I get exactly the same size (71mb) with the previous release tag, but on CI the binary is around 40mb, I'm still using 22.3.0 Java 11 on CI though... so maybe that's it

with -O1 I get 54mb locally

yeah, without -O1 the image is 71mb, so that mostly explains it...

yes

Would it be easy to change the code here to flag if lint-as is given for something clj-kondo doesn’t understand? It looks like it could be done if we replaced the ;; catch-all line with more specific [nil nil] maybe? And then the catch-all were flagging anything else? I’m trying to prevent situations when people add lint-as to something unsupported and it silently makes no difference without clj-kondo flagging that.

I'm not sure if :lint-as can be exclusively used for that list, I think lint-as can also be used for hooks but I'm not 100% sure

there was some edge case, can't remember the exact reason