OK, that makes sense. The code generated by the universal backend has long identifiers and plenty of whitespace so compression at that level will help a lot. Of course combining that with the tree shaker will give the best results.
Marc
On Sep 18, 2017, at 4:36 PM, James Baker james@waveformdynamics.com.au wrote:
Well the code size shrank considerably and the code still ran as expected, thats all I recall. Keep in mind though that some of the optimisations done by closure are whitespace removal / string substitutions etc which are decidedly less complicated than global analysis and dead code removal. I really couldn't tell you which level (simple / advanced) of optimisations that I tried. I was simply curious to see if it would help reduce the payload size is all.
Cheers,
James
On Mon, Sep 18, 2017 at 9:23 PM, Marc Feeley feeley@iro.umontreal.ca wrote: I’m with Adam on this subject. It would take some very fancy analysis for the Google Closure compiler to remove the code that Gambit’s tree shaker removes. Gambit can do it because it has knowledge about the structure and semantics of the generated code.
So when you say “it worked fine” I assume you mean the output code runs fine, not that Google Closure did a good job at removing dead code. Some benchmarking would be useful here!
Marc
On Sep 18, 2017, at 5:06 AM, James Baker james@waveformdynamics.com.au wrote:
I've tried Google Closure compiler previously on Gambit generated JS and it worked fine, it was a while ago and admittedly my scheme code wasn't doing anything overly complicated but still.
Cheers,
James
On Mon, Sep 18, 2017 at 5:10 PM, Adam adam.mlmb@gmail.com wrote: Sonny,
Gambit has its own register of global variables, which it keeps in some JS object. An external JS code tree shaker would not be able to distinguish what can be removed and what cannot as they - as far as I am aware - not introspect JS structures, but instead just look for unused identifiers/functions and remove those. And also it would not be able to remove what's not used.
So the whole way input code maps to JS code is beyond what JS code shaker's abilities.
However maybe my understanding of your JS tree shaker is not correct and it's so incredibly smart that it can cut through also such intricate code.
What about you give it a try and let us know here?
Adam
2017-09-18 0:36 GMT+08:00 Sonny To son.c.to@gmail.com: Have you considered running the output through google closure compiler for the tree shaking? thats what clojurescript does
On Sun, Sep 17, 2017 at 6:21 AM Adam adam.mlmb@gmail.com wrote: 2017-08-17 10:13 GMT+08:00 mikel evins mevins@me.com:
On Aug 16, 2017, at 9:11 PM, Marc Feeley feeley@iro.umontreal.ca wrote:
The JavaScript backend is being worked on actively this summer. It is in much better shape than 6 months ago. Currently we are working on implementing a tree shaker to reduce the size of generated code.
Nice!
Thanks,
--me
What's new with respect to the Javascript output now? _______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Marc