This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (6)
- # beginners (19)
- # boot (1)
- # cbus (2)
- # cider (3)
- # clara (24)
- # cljs-dev (4)
- # cljsrn (18)
- # clojure (168)
- # clojure-boston (1)
- # clojure-dev (55)
- # clojure-russia (199)
- # clojure-sg (2)
- # clojurescript (38)
- # clojurex (1)
- # core-async (15)
- # css (16)
- # cursive (62)
- # datomic (23)
- # editors-rus (17)
- # events (3)
- # funcool (1)
- # hoplon (360)
- # ldnclj (37)
- # lein-figwheel (11)
- # leiningen (1)
- # nginx (1)
- # off-topic (13)
- # om (361)
- # onyx (1)
- # re-frame (56)
- # reagent (24)
- # robots (1)
- # spacemacs (46)
- # yada (9)
Finally got a chance to run our code base with direct linking enabled for everything tonight. Breaks our test suite but only in a minor way: we have Expectations and use
side-effects which does a redefinition, which of course requires
Overall there seems to be a small performance improvement but I'll need to do more benchmarking to see how it will work in practice.
As far as the tests are concerned, it'll be easy enough to have direct linking enable for non-dev/CI runs but it highlighted that some of our (early) tests rely on
with-redefs where there don't need to (we should refactor to improve composability instead).
@alexmiller: do you think it would be possible to release 1.8 (when the time comes) both direct linked and "normal"?
@bronsa: There's already the
-slim JAR release, which contains just
.clj files and compiled Java.
ideally I think we should distribute a "dev" clj with DL and inlining off and a "prod" clj with DL and inlining on
That sort of thing has been discussed before http://dev.clojure.org/display/design/Build+Profiles
:inline and direct linking are stuff that's really good for production code but doesn't play well in a dev env
There's a downside too: people may see something work in a REPL and be surprised when it doesn't work in production. AOT-compilation already creates headaches like that.
the downside of the build profile stuff (especially if you actually want to run tests for both) is that it makes the build much more complicated, esp if you want to release all the profiles as the same "build"
I have a lot of work on it stashed away somewhere. I actually ended up removing all the legacy ant stuff in the process.
I spent a lot of time in 2014 thinking about this b/c technically you could have the same question for all of your lib dependencies so you potentially get an explosion of combinations. is that useful? prob not. maybe it's not even a real problem since most people don't aot libs.
we considered also removing all the non-essential metadata (docstring, etc) for the prod build as that stuff ends up in the constant pool and does have some effect on loading, size, etc.
For consistency of testing, I would much prefer using "production-like" code for dev and testing too.
I got our dev build/test working with full DL but at the expense of explicitly annotating a few functions with
^:dynamic purely because we mock them in tests.
My goal now is to change the code and how we test it so we don’t need to do that, so we can use DL for dev without workarounds.
linking vars with invokedynamic should give production performance with no loss of dynamicity
Maybe now we have DL, Clojure/core will be persuaded to drop Java 6 and implement invokedynamic?
indy is more performant after 8u20 -- for extreme users like Nashorn/jruby. for clojure usages are relatively minimal
no offense to clojure-android users, I just don't feel like it merits holding the JVM back
indy could be certainly handled with a flag. whether it interferes with ProGuard is tbd.
cursive/intellij can run and debug code on Java 8, including lambdas (which are implemented with invokedynamic). what's the problem?
The story is hella funny: oracle never have and won't ship a OSX JVM with good font rendering in it's GUI toolkits. So instead, every IntelliJ/eclipse/etc user ends up using apple's very old fork of 1.6 JVM to get font rendering that's reasonable. Jetbrains even recommend using it (even though it's old and has known security flaws). IntelliJ 15 iirc has a Jetbrains fork of 1.8 JDK that fixes font rendering on OSX
But obviously that doesn't help users on old IntelliJ versions. Cursive needs JVM 1.6 support because it has to run in the JVM that the IDE is in, not the JVM your application code is in