This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-09-07
Channels
- # announcements (10)
- # aws (2)
- # beginners (134)
- # cider (30)
- # cljs-dev (44)
- # clojure (130)
- # clojure-dusseldorf (3)
- # clojure-italy (27)
- # clojure-nl (48)
- # clojure-spec (32)
- # clojure-uk (63)
- # clojurescript (76)
- # core-logic (5)
- # cursive (11)
- # datascript (2)
- # datomic (34)
- # emacs (5)
- # figwheel (13)
- # graphql (1)
- # java (7)
- # jobs (10)
- # jobs-discuss (17)
- # juxt (1)
- # leiningen (16)
- # luminus (10)
- # mount (3)
- # off-topic (42)
- # om (1)
- # onyx (1)
- # pedestal (7)
- # re-frame (40)
- # reagent (81)
- # ring (1)
- # shadow-cljs (32)
- # spacemacs (5)
- # testing (1)
- # tools-deps (51)
- # calva-dev (25)
- # figwheel-main (55)
- # 100-days-of-code (1)
All this perf work is super awesome! :clap: Do you do any benchmarking of incremental builds as well?
@ No. These benchmarks (over the Coal Mine corpus) tend to run long enough to warm up the JVM, which I suspect accurately reflects what happens if you are using a long-lived Figwheel session. But building with cached artifacts is a whole other perf story I’m not currently measuring.
Yeah, was mostly thinking of code paths that are only run on incremental compilation. Thanks :pray:
It seems that tools.reader 1.3.0
is not fully compatible with clojurescript 1.10.339
at least for reading namespace qualified keywords (in current namespace)
(r/read-string "::foo")
yields an exception.
I can reproduce it in the cli, with this command:
clj -Sdeps '{:deps {org.clojure/clojurescript {:mvn/version "1.10.339"} org.clojure/tools.reader {:mvn
/version "1.3.0"}}}' -m cljs.main --repl-env node -e "(ns foo.core) (require '[clojure.tools.reader :as r]) (r/read-string \"::foo\")"
I get this exception:
Exception in thread "main" clojure.lang.ExceptionInfo: /private/var/folders/l0/xhq1bf0x59lgpnnd7jglqb0r0000gn/T/out3192
375010680971978279779396035683/cljs/tools/reader.js:1604
throw e;
^
Error: Invalid token: ::foo
https://github.com/clojure/tools.reader/blob/master/src/main/cljs/cljs/tools/reader.cljs#L376
This works:
clj -Sdeps '{:deps {org.clojure/clojurescript {:mvn/version "1.10.339"} org.clojure/tools.reader {:mvn/version "1.3.0"}}}' -m cljs.main --repl-env node -e "(ns foo.core) (require '[clojure.tools.reader :as r]) (binding [*ns* 'aa] (r/read-string \"::foo\"))"
Has something changed with clojurescript 1.10
?
In 1.9
it worked without any special bindings.
@viebel Perhaps this change: https://github.com/clojure/tools.reader/commit/c56d9ef4a2b705080a473f181207649f9c09dee8
Found a perf boost for :parallel-build
which ends up being 16% faster on smaller codebases (like the compiler's unit tests, for example)
Doing some more testing to ensure single-threaded perf doesn't regress.
https://dev.clojure.org/jira/browse/CLJS-2896
Fairly simple change: https://github.com/mfikes/clojurescript/commit/fc66a5a558b2749c93e1d29605bb69d58f0ad36f
Yeah, and perhaps another reason is simply a little more parallelism, especially if you have more cores than files
Well, for something like Coal Mine, there are a lot of files, so the cores are kept busy, and where you really see the difference is in that rampdown that occurs at the end, when there are straggler files still being built
But, yeah, I don’t fully appreciate all of the consequences yet :slightly_smiling_face:
FWIW, I tried adding parallel reading, but that made no difference as reading is so fast
Cool, patch is now in https://dev.clojure.org/jira/browse/CLJS-2896 if anyone cares to try it on their codebase
@mfikes nice I now consistently see basic compile times under 9 seconds on my desktop machine for the runtime tests
@jmb Thanks for the patch in CLJS-2849. This appears to be your first contribution. Have you submitted the CA?
@kucerm2 I left a comment for you in https://dev.clojure.org/jira/browse/CLJS-2868 (For some reason I can’t assign the ticket to you.)