Enable AOT and direct linking

[jeaye]

No description provided.

[jeaye]

I'm thinking the travis build has hit that deadlock you mentioned.

[ztellman]

I definitely don't want Clojure as a permanent dependency of this project, that can lead to problems down the road. Can you expand on what this enables?

[ztellman]

And yes, there's some problem with the tests I need to track down, unrelated to your changes.

[jeaye]

AOT and direct linking are both performance improvements.

AOT

Compiles all namespaces ahead-of-time, into bytecode, rather than just packaging the source into a jar. This can have load time and run-time performance effects. Clojure was added as a dependency, since the uberjar will contain Clojure; I've moved the dependency to only the uberjar profile.

Direct linking

By default, each fn call in Clojure looks up the var first, then performs the call. With direct linking, the var lookup is removed; the cost of this is the lack of rebinding vars. In the REPL, we do this by just redefining them, or manually altering their roots. In production, this is rarely needed. For this library, I see no reason why it should be there.

It's curious that you wouldn't want Clojure as a dependency for a Clojure project though. What's your reasoning?

[ztellman]

I understand what both of them are, I just haven't heard of them being used at the library level before. Typically this is something you'd configure for your top-level application. Likewise, I don't want to put the Clojure version in there because that's something that should be defined at the application level.

[jeaye]

Okie dokie, let's close this guy then. Thanks! I'm looking forward to the Clojars deploy. :)