[gambit-list] Status of javascript output

Marc Feeley feeley at iro.umontreal.ca
Mon Sep 18 16:40:14 EDT 2017


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 at 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 at 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 at 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 at 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 at 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 at gmail.com> wrote:
> > 2017-08-17 10:13 GMT+08:00 mikel evins <mevins at me.com>:
> >
> >> On Aug 16, 2017, at 9:11 PM, Marc Feeley <feeley at 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 at iro.umontreal.ca
> > https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
> >
> >
> > _______________________________________________
> > Gambit-list mailing list
> > Gambit-list at iro.umontreal.ca
> > https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
> >
> >
> > _______________________________________________
> > Gambit-list mailing list
> > Gambit-list at iro.umontreal.ca
> > https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
> 
> 
> 
> Marc
> 
> 
> 
> 




More information about the Gambit-list mailing list