This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-06-01
Channels
- # beginners (133)
- # boot (59)
- # cider (5)
- # cljs-dev (30)
- # cljsrn (23)
- # clojure (212)
- # clojure-austin (3)
- # clojure-brasil (1)
- # clojure-chicago (5)
- # clojure-italy (10)
- # clojure-russia (5)
- # clojure-serbia (1)
- # clojure-spec (34)
- # clojure-turkiye (2)
- # clojure-uk (132)
- # clojurescript (163)
- # clojutre (1)
- # cursive (5)
- # datomic (58)
- # emacs (42)
- # events (1)
- # graphql (26)
- # hoplon (16)
- # jobs (1)
- # lumo (27)
- # numerical-computing (3)
- # off-topic (127)
- # om (9)
- # onyx (24)
- # re-frame (20)
- # reagent (20)
- # ring-swagger (14)
- # sql (19)
- # unrepl (28)
- # untangled (3)
- # vim (8)
- # yada (17)
Actually things are faster now (185 seconds) compared to a couple of years ago. But, to achieve this I had to add -Xmx8g
.
This doesn’t appear to give the compiler more memory, but instead constrains it. With -Xmx8g
it seems to actually use around 4GB (per Activity Monitor), and without it, it uses 12GB, but runs slower (310 seconds).
counterintuitively, using less memory with the JVM can improve performance, as there is less heap for the GC to churn
but really, it depends and there a lot of knobs to tune
Yes. I explicitly gave it 64GB (the box has 128GB) and it slowed things down a little. Alternatively, I kept it at 8GB, but turned on G1, and that also slowed things down a little.
But, the interesting thing is that, letting it manage its own cap (not specifying any -Xmx
) appears to be really bad. Perhaps the Java 8 VM interacts badly with macOS in this case.
High level summary:
-Xmx8g
: (really uses about 4GB) -> 185 seconds
<no setting>: (really uses about 12GB) -> 310 seconds
-Xmx64g
: (really uses about 22GB) -> 197 seconds
Updated CLJS micro-benchmarks: http://blog.ducky.io/clojurescript-benchmarks/full/20170524/index.html
For example, this one change by thheller, CLJS-1879, lead to a big improvement in usage of cljs.core/str
macro usage. http://blog.ducky.io/clojurescript-benchmarks/full/20170524/index.html#bench-150
my fault
I’m curious as to the effect (as well as correctness) of the patch in https://dev.clojure.org/jira/browse/CLJS-2066
The perf optimization is probably not broadly applicable, but makes compilation of for
constructs with lots of bindings fast. (It makes the fifth-postulate
test mentioned above run in a quarter of its original time, for example.)
@mfikes that actually sounds like a good idea - we don’t need to look at the bodies, we just need the arity analysis
@dnolen It may need some more vetting. I just noticed that it causes an odd failure in self-host. Adding a comment to the ticket.
@mfikes and you’re sure those self-host failures are from this patch? (just asking since we patched shadow stuff yesteday)