search

clj-commons / byte-streams

A Rosetta stone for JVM byte representations
417 stars 33 forks source link

Enable AOT and direct linking #28

Closed jeaye closed 7 years ago

jeaye commented 7 years ago

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

ztellman commented 7 years ago

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 commented 7 years ago

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

jeaye commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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