This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-11-13
Channels
- # 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 ^:dynamic
.
After I'd annotated a handful of functions with ^:dynamic
everything passed.
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.
That might work as a non-direct-linked version.
@stuartsierra: I'm aware of that, but AOT non-direct is still faster to load than JIT
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
both :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.
this idea seems at odds with where we are in the release cycle though
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
And that requires a compiler change and being Java 7+ only
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
Do we know what % of Clojure users are on which versions of Java these days?
no offense to clojure-android users, I just don't feel like it merits holding the JVM back
well, Colin has also raised the issue of being unable to move Cursive off jdk 1.6
indy could be certainly handled with a flag. whether it interferes with ProGuard is tbd.
I have a State of Clojure survey prepped and hope to put it out after the conj
had hoped to do it this week, but too busy
cursive/intellij can run and debug code on Java 8, including lambdas (which are implemented with invokedynamic). what's the problem?
@ghadi @alexmiller I think IntelliJ 15 or whatever the latest is fixes cursive's reliance on 1.6 JDK
Ask @cfleming for details- he's been the biggest advocate for keeping 1.6
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