cljs - Shrink advanced-compiled scripts by removing error messages

[Tom Connors]

I've been looking for ways to produce smaller scripts, and one plausible approach is to remove or simplify exception messages. I've never found the error messages I get from advanced-compiled builds to be helpful and I wouldn't miss them if they were gone. Reactjs currently does something similar to what I'm proposing.

Suppose the clojurescript compiler gets a new option, "shrink-error-messages", and the core library exposes a new macro, "removable-error-message".

When writing code that throws errors we could replace:

`(throw (js/Error (str "Invalid arity: " (.-length arguments))))`

with

`(throw (js/Error (removable-error-message "Invalid arity: " (.-length arguments))))`

When "shrink-error-messages" is false, those two examples would produce the same output, but with shrink-error-messages=true, the macro would return "(removed)", or some other short string - perhaps this could be configurable. Another option would be to produce "Error 1234", where 1234 is the key of the error in a lookup table that is generated during compilation and spat out in some file next to the compiled js file.

In my testing, doing this to just cljs.core saves 2KB after gzipping.

Would this change be likely to be accepted?

[David Nolen]

I believe cljs.core is 22-25K gzipped. So 2K is a 8-9% savings. On its own it doesn't really seem significant enough to bother and the desire for the introduction of knobs here is not a good sign. I'd like to see a comparison with a more general strategy (and no new knobs) like lookup tables for smallish strings like we do with keywords and symbols. i.e. you would get it with `:optimize-constants true` (which is set by default when you use `:optimizations :advanced`).

I'm also less interested in the cljs.core size beyond FUD control. It would be important to also see the impact of the above on medium to large ClojureScript codebases.

David

--
You received this message because you are subscribed to the Google Groups "Clojure Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure-dev...@googlegroups.com.
To post to this group, send email to cloju...@googlegroups.com.
Visit this group at https://groups.google.com/group/clojure-dev.
For more options, visit https://groups.google.com/d/optout.

[Nathan Fisher]

Java has string interning. Is that approximately how you would see the lookup table working?

--

- sent from my mobile

[David Nolen]

That's the idea yes, but it's already been implemented for keywords & symbols. It just needs to be extended to handle small strings.

David

[Thomas Heller]

FWIW the Closure Compiler has a AliasStrings pass to do this but their conclusion seems to be that its not worth the effort and may actually hurt gzip performance.

https://github.com/google/closure-compiler/blob/4c97e69df965da4179b639ea3ee2020c98cc3621/src/com/google/javascript/jscomp/AliasStrings.java#L40-L46

The related options can be configured on the CompilerOptions instance we already have

(.setAliasableStrings co #{"foo" "bar"})

or

(.setAliasAllStrings co true)

Might be useful to expose these options to allow easier experimentation. 

Cheers,

/thomas

[Tom Connors]

My assumption was that something like "optimize constants" for strings would be pointless without other changes, because closure would just inline those strings wherever they're used anyway. That's why I'm interesting in removing the strings entirely.

Another plausible approach would be for the compiler to provide a hook to allow modifying the AST or maybe just the raw forms, like a whole-program macro. Then any user that wants to strip out error messages could replace any list starting with js/Error with (js/Error "redacted").