This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-11-22
Channels
- # beginners (122)
- # boot (217)
- # cider (14)
- # cljs-dev (74)
- # cljsrn (22)
- # clojure (101)
- # clojure-nl (4)
- # clojure-russia (22)
- # clojure-taiwan (5)
- # clojurescript (87)
- # cursive (4)
- # datavis (2)
- # editors (3)
- # hoplon (2)
- # jobs (2)
- # ldnclj (1)
- # lein-figwheel (1)
- # luminus (1)
- # off-topic (1)
- # om (105)
- # onyx (37)
- # reagent (2)
- # spacemacs (2)
@dnolen I built a thing, not sure if you'd be interested to have it in cljs.core. basically all of :optimize-constants
as a Closure compiler pass instead of what is currently done in the analyzer/compiler. did it as an experiment but it turns out it has some advantages over the current implementation in cljs.
@dnolen less issues with incremental compilation mostly since it always optimizes everything you don't need to worry about having some files compiled with :optimize-constants
and others without
I would have thought that cross module motion would take care of that but somehow it doesn't currently in cljs
:optimize-constants
currently has to do a ton of book keeping and checking in caches to make it all work
yeah I’m not really all that concerned about the first thing - :optimize-constants
is rarely explicitly used.
and interesting counterpoint would be that optimizing constant data structures - vectors, sets, maps
is still likely to happen in the future, perhaps a little more annoying to identify after the fact
well technically detecting whether something is constant or not can be done based on the AST as well
the code motion not working is probably related to all constants being in cljs.core.cst...
doing keywords and symbols are pretty simple and it’s good to see that’s the case even directly in Closure
don't know why closure doesn't move them given they are globals vars after optimization
so another thing add to list of tradeoffs in favor of solving this at the Closure level