Speedup of 1.13 for the last commit https://github.com/mfikes/cljs-perf

That puts us at 2.26 relative to 1.10.339

execution speed or compilation speed?

Compilation speed

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\")"

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

@viebel auto-namespaced keywords require special bindings and are not valid edn

@thheller What do you mean by special bindings?

are you referrint to *alias-map*?

I think so yes. can't remember the exact name.

I think its *ns* in this case though

https://github.com/clojure/tools.reader/blob/master/src/main/cljs/cljs/tools/reader.cljs#L376

*alias-map* is for readfing ::foo/bar

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.

not that I'm aware of no. what did 1.9 return if you don't actually bind *ns*?

It returned cljs.user/foo

I am not 100% sure. At least, in self-hosted cljs (e..g in Klipse) it worked

@viebel Perhaps this change: https://github.com/clojure/tools.reader/commit/c56d9ef4a2b705080a473f181207649f9c09dee8

Thanks @mfikes. The commit description is pretty clear: “fail on nil ns”

@viebel probably how it worked before was accidental

since not that many people relied on that also unlikely to do anything about it

No worries @dnolen I found a way to fix my code.

👍:skin-tone-4:

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

@mfikes hrm interesting, so not stalling on io

Yeah, and perhaps another reason is simply a little more parallelism, especially if you have more cores than files

I’d be surprised if that’s not faster for even larger code bases?

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

I’m nearly done testing it, and will make the patch available

But, yeah, I don’t fully appreciate all of the consequences yet 🙂

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

approved & re-assigned

Nice 🙂

@mfikes hi, my transaction ID of CA is CBJCHBCAABAAr-OiYOiJgrZUTHv2MzSVy9txqxESM6hY

Thanks!

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

does ClojureScript read deps.cljs from :local/root dependencies?