Clojurians
#cljs-dev
<
2018-10-01
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

thheller06:10:01

I'm worried that this may get a little overzealous and construct all constants on startup which may affect performance on startup similar to clojure. especially with regards to [:h1 {:style {:color "red"}} "hello world"] hiccup data (eg. reagent) or even (get-in something [:foo :bar]) smaller constants

thheller06:10:34

also closure is not great at detecting CLJS collections as dead code so it may end up never removing those

thheller06:10:43

although delay does address this

mfikes11:10:59

Yeah, an optimization like this would only make sense if it improves performance.

mfikes11:10:34

I tried a revision that uses delay and it looks like you still get the perf benefit, at least for

(simple-benchmark [] (special-symbol? 'if) 1000000)
this gave me these speedups (which must be exhibiting some noise because some are faster than the non-delay approach): V8: 1.45, SpiderMonkey 2.8, JavaScriptCore 2.7, Nashorn 1.2, ChakraCore 2.3, GraalVM 1.5 Wonder if I made a mistake, but that change is here https://github.com/mfikes/clojurescript/commit/ed57dc7cf0dbcf61c26f55a2b662e89f4092cac6

mfikes11:10:37

If curious, here is the kind of code you get at the call site

var $x$jscomp$inline_881$$ = $cljs$core$cst$0sym$0if$$;
$cljs$core$contains_QMARK_$$($cljs$core$_deref$$($cljs$core$cst$0set$0set_DASH__DASH_1359805939$$), $x$jscomp$inline_881$$);
with the constant table containing
$cljs$core$cst$0set$0set_DASH__DASH_1359805939$$ = new $cljs$core$Delay$$(function() {
return new $cljs$core$PersistentHashSet$$(null, new $cljs$core$PersistentArrayMap$$(null, 24, [$cljs$core$cst$0sym$0_AMPERSAND_$$, "null", $cljs$core$cst$0sym$0case_STAR_$$, "null", ...
...
$cljs$core$cst$0sym$0throw$$,
  "null", $cljs$core$cst$0sym$0def$$, "null"], null), null);
})

mfikes11:10:29

I think the test above could be invalid, though... I think there is a problem where some of the constants inside that map are being defined later. Let me fix that and retry to be sure things are actually more performant, and I'm not just measuring against a set full of null values.

mfikes12:10:48

OK good. Fixing that by at least dumping symbols and keywords into the constant table first leads to the same perf gain.