• While minifying modules currently the Google closure compiler will be used with SIMPLE optimization (=default without the @compilation_level ADVANCED_OPTIMIZATIONS annotation).

    Moray gave an example of using advance optimization while he was refactoring the BME module. → http://forum.espruino.com/conversations/­277165/

    There is still a little imperfection already stated: The basic rule is refer to anything you don't want minified as an indirect property reference, so me.property should be written as me['property'].
    This blights the code a little bit and can be avoided be giving the closure compiler the knowledge which code you want to keep. Moray already mentioned the "extern" approach http://forum.espruino.com/comments/12636­552/. A simple usage scenario (without parameters) would be enough. Here is an example of the HTU21D module:

    var htu = exports.connect( null );
    var t1 = htu.RH_12_BITS_TEMP_14_BITS;
    var t2 = htu.RH_8_BITS_TEMP_12_BITS;
    var t3 = htu.RH_10_BITS_TEMP_13_BITS;
    var t4 = htu.RH_11_BITS_TEMP_11_BITS;
    htu.isMeasuring();
    htu.readTemperature();
    htu.getTemperature( null );
    htu.readHumidity();
    htu.getHumidity();
    htu.getCompensatedHumidity( null, null );
    htu.getDewPoint( null, null );
    htu.softReset();
    htu.getResolution();
    htu.setResolution( null );
    htu.isEndOfBattery();
    htu.isHeaterOn();
    htu.setHeaterOn( null );
    htu.getSerialNumber();
    

    Now you can leave all the module code and advanced optimization works fine. But from where should we take this usage code for every module?

    1. Write it manually
    2. Extract it from the code annotations
      Google itself has an @export notation but then you have to use the Google Closure Library → not applicable.
      Parse/Grep would be possible but it's a lot of work until reaching a stable version for all possible cases.
    3. Using a precompiler like TypeScript. Type information is available and it's seems Google is enhancing the minifier with some TypeScript support. For me this is the most promising option because I write modules in TypeScript and the advantage of using TypeScript at all is huge. But I think many module developers do not share this opinion - up to now. We'll see us in one year. ;-) But there is currently no out-of-the-box solution.

    Currently I prefer 1) because it's straightforward and easy realizable and additionally leaves option 2) and 3) open.

    Later it would be possible to enable advanced optimization in the IDE. This would be really great to remove all unused code during save().

    What do you think about adding a simple extern/usage file for every module and compile the modules with advanced optimization? This would not be a huge one-step-solution. Every module can decide by itself:

    • No extern file available → simple optimization
    • extern file available → advanced optimization

    A few numbers for the motivation behind:

    • HTU21D.js: 14391 bytes, simple minified: 3802 bytes, advanced minified: 2400 bytes
    • MLX90614.js: 4867 bytes, simple minified: 1714 bytes, advanced minified: 1166 bytes
    • MAG3110.js: 8219 bytes, simple minified: 2547 bytes, advanced minified: 1542 bytes
    • MCP9808.js: 12928 bytes, simple minified: 3745 bytes, advanced minified: 2427 bytes

    Code sizes shrink about 30% to 40% when switching from simple to advanced optimization.

    BTW: The Google webservice is slow with ADVANCED_OPTIMIZATIONS and denied after using too often. I wrote a local build script. It uses exactly the same directory/file convention so no customization is required. It's faster and no additional installation except Java is required (Google Closure Compiler is a Java program). I would make it available if somebody is interested...

    And that could be the roadmap:

    Any thoughts?

About

Avatar for luwar @luwar started