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

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

although delay does address this

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

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)

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$$);

$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);
})

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.

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