You're not going to see any problems with a hash map like this that is never used. However imagine if you use a top level map as a switch or a configuration where one of keys is accessed and the value used by consuming code. None of the other key/value pairs are going to get eliminated. Closure doesn't know anything about ClojureScript maps, it cannot eliminate properties you never use the same way it can (given some attention) when using Plain Old JavaScript Objects.
Again the rule of thumb stands. Just don't do if you care about dead code elimination. And this is really something for library designers to be concerned about, *not* application developers. I would never point this out in application code. However cljs-time is a very large *library* dependency that should be concerned about dead code elimination issues. David On Wed, Mar 11, 2015 at 1:08 AM, Gregg Ramsey <[email protected]> wrote: > This is puzzling. I have just run some tests and top level data structures > do appear to be eliminated. > > For example: (def x {:a "XXXXXXXX" :b 2}) > > I was NOT able to find the string "XXXXXXXX" in the JavaScript compiled > under ":optimizations :advanced". > > Can you provide any more clarity on this rule? > > > On Wednesday, 11 March 2015 13:49:52 UTC+11, David Nolen wrote: > > If you want your library to be dead code elimination friendly don't use > top level data structures. > > > > > > It's a very simple rule. > > > > > > David > > > > > > On Tue, Mar 10, 2015 at 8:19 PM, Mike Thompson <[email protected]> > wrote: > > This issue from David Nolen, caught my eye: > > > > https://github.com/andrewmcveigh/cljs-time/issues/21 > > > > > > > > Feels like there is important information there, but I just don't know > enough to interpret what's said. Can anyone help? > > > > > > > > If I have this: > > > > > > > > (def x {:a 1 :b 2}) > > > > > > > > David is saying that x can't be dead-code-eliminated. Correct? > > > > > > > > If so, the solution he talks about is? > > > > > > > > ;; Replacing PersistentHashMaps with functions? Can't be right. I think > I'm being too literal here > > > > (def x ((fn [] {:a 1 :b2}))) > > > > > > > > ;; more likely this? > > > > > > > > (defn x > > > > [] > > > > {:a 1 :b 2}) > > > > > > > > Ie. you must now "call" x to get the map. > > > > > > > > If this solution is the right one, doesn't that mean we would be > inefficiently constructing the (potentially large) hashmap inside x on each > call. > > > > > > > > -- > > > > Mike > > > > > > > > > > > > -- > > > > Note that posts from new members are moderated - please be patient with > your first post. > > > > --- > > > > You received this message because you are subscribed to the Google > Groups "ClojureScript" group. > > > > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected]. > > > > To post to this group, send email to [email protected]. > > > > Visit this group at http://groups.google.com/group/clojurescript. > > -- > Note that posts from new members are moderated - please be patient with > your first post. > --- > You received this message because you are subscribed to the Google Groups > "ClojureScript" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/clojurescript. > -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/clojurescript.
