Fork me on GitHub
#cljs-dev
<
2017-06-01
>
mfikes00:06:56

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).

Alex Miller (Clojure team)00:06:06

counterintuitively, using less memory with the JVM can improve performance, as there is less heap for the GC to churn

Alex Miller (Clojure team)00:06:38

but really, it depends and there a lot of knobs to tune

mfikes00:06:06

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.

mfikes00:06:47

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.

mfikes00:06:18

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

thheller05:06:56

how the heck does the compiler use 22GB? what are you building? 😛

thheller11:06:04

ah that beast … 🙂

rohit12:06:14

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

thheller12:06:15

@rohit hehe that is technically cheating

thheller12:06:05

since the change enabled the code to be removed or inlined by the closure compiler

rauh16:06:03

IFind should go into fast-path-protocols, right?

dnolen16:06:10

we may want to benchmark whether fast-path-protocols matters anymore

dnolen16:06:24

it made a huge diff on Firefox, and less so on V8/JSCore

mfikes18:06:13

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.)

rauh18:06:15

@mfikes Does a letfn also do the 2-pass? If not for could be redone with letfn?

mfikes18:06:39

Good question! I don’t know 🙂

dnolen18:06:32

@mfikes that actually sounds like a good idea - we don’t need to look at the bodies, we just need the arity analysis

mfikes18:06:38

@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.

dnolen18:06:14

@mfikes and you’re sure those self-host failures are from this patch? (just asking since we patched shadow stuff yesteday)

mfikes18:06:48

Oh… good point. Will back out my change and see if they fail on its own.

mfikes19:06:23

@dnolen Your intuition is correct. Adjusting JIRA…

dnolen19:06:40

@mfikes cool, thanks!

thheller21:06:09

oh oh I smell trouble

thheller21:06:42

hoping their own ES6 support works for those