@mfikes I just improved the compiler performance a bit (like ~20%). But not sure about the impact on self host. Test seem to pass, but if you have a second, could you test the perf?

@rauh Yes. Is there a patch somewhere?

https://gist.github.com/rauhs/8f8a7d50d8485583f65d2b2c85b26983

I'll create a ticket + patch if the perf seems to be good.

Cool. I can try compiling Andare, or other large namespaces and let you know.

@mfikes Sorry just changed (first (.next it)) to (key (.next it)) which should be faster. Gist updated.

OK. Also, I’d recommend (.-length ns) over (alength ns)

Good point. Will edit.

@rauh I see no change in perf for (require 'cljs.core.async). I forget, does this code benefit if you have a lot of namespaces at play?

@mfikes I think so, yes.

Hmm… wait, I seem to remember benchmarking this by seeing how long it takes the (JVM) compiler to compile Planck’s code. Will try that.

:compiler-stats

I benchmarked the JVM side on my project and it's roughly 20% for me locally. But I have a LOT of namespaces

script/test-self-parity involves a boat-load of self-host compilation. I’ll try that as well.

No speedup when compiling Planck (`:compiler-stats`)

@rauh I see no speedup when running script/test-self-parity

@mfikes Ok thanks, but no regression either, right? For me the results: https://dev.clojure.org/jira/browse/CLJS-2424

Right, I get 0 failures, 0 errors with the patch.

@mfikes Looks like it's mostly a speedup on recompile, not so much on initial compilation

@mfikes If you want to test recompile speed you can remove all JS output files, then simply touch a single CLJS file and the entire project should recompile when you "watch" the project. That's the how I measure the recompile performance.