lein droid compile time -- Compiling neko.listeners.adapter-view

[Timothy Pratley]

Hi,

lein droid compile

appears to spend a long time in

Compiling neko.listeners.adapter-view

(Another explanation is that it is the last task, and other post processing is taking the time).

It seems that there is no need to perform this compilation.

neko could be a pre-compiled dependency... only my code should need compiling?

I tried setting :aot :all in

https://github.com/clojure-android/neko/blob/master/project.clj

But that does not compile, because it needs Android dependencies (From the SDK?)

I was hoping to try using a checkouts link to a fully compiled neko,

but I'm not seeing how to tell neko where to find Android.

Any suggestions?

Regards,

Timothy

[Alexander Yakushev]

Hello Timothy,

You are right that it's some post-processing that takes time, not the compilation of that namespace. For some reason I couldn't figure out what exactly it was doing, and it is kinda elusive — this delay appears intermittently.

Distributing AOT-compiled libraries usually does more bad than good. Anyway, the libraries should be compiled only once per project (unless you do "lein clean", of course) so it's not so big deal to wait little extra just once.

You can build Neko yourself by doing "lein droid jar" inside it's directory. If you want all its classes to AOT-compile, then put :aot :all-with-unused inside :android map of the project.

Best regards,
Alex

[Timothy Pratley]

Gotcha, yes that makes sense.

Interesting thing about the post-processing is that for the same project one of my colleagues does not experience the delay, but another does. I guess something environmental is occurring. Any tips on how I can investigate it? I think I will add a bunch of printf into lein-droid and see what I can find.

[Alexander Yakushev]

I already tried println-debugging with no luck but maybe you will be more successful. Perhaps it's still better to take a profiler and analyze in which function/method `lein droid compile` spends that extra time.

[Timothy Pratley]

When I compiled the latest version 0.2.4-SNAPSHOT from github, the long delay went away!

[Alexander Yakushev]

That's weird because I'm using the same version and the delay stands for me. Also I was unable to get any insight on what's going on using VisualVM.

[Timothy Pratley]

Hi Alexander,

Calling shutdown-agents resolved the issue for me. If anything in the compile phase uses a future or causes the agent thread pool to be used, it introduces this delay. I've submitted a pull request. Avoiding the delay saves a lot of time.

Regards,

Timothy.