I plan on writing a minification documentation page which explains all of this and the take-aways from my (and Josh’s) efforts.
> On Dec 29, 2021, at 8:09 AM, Harbs <[email protected]> wrote: > > Let me qualify that. > > If you use "-js-dynamic-access-unknown-members=true” all untyped members are > quoted. > > If you don’t use "-js-dynamic-access-unknown-members=true”, then the > minification even without exports should work fine, but then you need to make > sure you quote any Object members where the name is significant (i.e. data > coming from JSON, etc.) > > If you need "-js-dynamic-access-unknown-members=true”, then you will get > accessor mismatches unless you consistently use data types and not “Object” > or “*”. Included in that is access to Array members (i.e. myArray[i].fooBaz() > is a no-no because it will get quoted on output). Neither Jewel nor MX/Spark > was written with that in mind. It’s fixable, but it will take time. I fixed > the general framework classes, but those component sets were not within scope > for me. > > HTH, > Harbs > >> On Dec 29, 2021, at 8:01 AM, Yishay Weiss <[email protected] >> <mailto:[email protected]>> wrote: >> >>> 1. Jewel does not look like it can be aggressively minified. (Spectrum can.) >>> 2. MX/Spark does not look like it can either. >> >> Can you explain this? >> >> >> From: Harbs<mailto:[email protected] <mailto:[email protected]>> >> Sent: Tuesday, December 28, 2021 11:36 PM >> To: Apache Royale Development<mailto:[email protected] >> <mailto:[email protected]>> >> Subject: Re: Compiler options for reducing release build size of Royale >> projects (Part 2) >> >> After 2 weeks of intense work, I got my app fully functional with the >> options below. >> >> Here’s in short what I did: >> >> 1. I audited as many cases of quoted access I could in the unminified JS >> code. Any place where it was accessing something on a class/instance was >> because the compiler couldn’t figure out the type. >> 2. I added types to all the places I could find. I basically eliminated >> every use of :Object and :* that I could. >> 3. I used Vectors where I could (using the -js-vector-emulation-class=Array >> option) >> 4. I removed unknown class accessors (no looping through classes and calling >> static methods) >> 5. Removed all the dynamic bracket access and assignment. (no for-ins on >> class instances, etc.) >> >> In my travels I discovered that: >> 1. Jewel does not look like it can be aggressively minified. (Spectrum can.) >> 2. MX/Spark does not look like it can either. >> 3. I need to heavily modify my already modified version of TLF to get it to >> work with minification. >> 4. There was some unnecessary Reflection and Vector dependencies in >> framework code which I fixed. >> 5. Class names is a prime candidate for code removal, and (besides >> reflection) the current roadblock with that is SimpleCSSValuesImpl which >> accesses ROYALE_CLASS_INFO. If we can eliminate that, I’d save 66KB (12KB >> gzipped) in my app. >> 6. It’s worthwhile to use protected methods for event listener callbacks, >> because the long-winded private method names end up in the minified code. (I >> still need to address this.) >> >> End results: >> >> Before my effort, my app was 2,903,814 bytes and 777,071 bytes when gzipped >> Afterwards: 1,989,596 bytes and 621,851 bytes gzipped >> >> That’s a savings of 1MB before gzipping (about 1/3) and 155KB after >> gzipping. (about 20% reduction) >> >> If we can get rid of the class names we can get down to: 1,923,653 >> bytes/610,493 bytes. >> >> A little over 600KB is a totally reasonable size for an application of this >> size and complexity. The Flash version was MANY times that and has a LOT >> less code. >> >> This turned into somewhat of an obsession for me, but I’m pleased with the >> results. :-) >> >> HTH, >> Harbs >>> On Dec 16, 2021, at 8:54 PM, Harbs <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Well I spent more time. Besides the XML issues which are pretty much >>> resolved, I ran into: >>> >>> 1. I have a setter in a class which was removed by the goog dead code >>> removal. I worked around it by turning the setter into a method. I’ll see >>> if I can come up with a minimal test case on that. >>> >>> 2. I have a library which has a LOT of dynamic pieces. I spent a LONG time >>> trying to assign types to places where I was getting runtime errors. I now >>> got to the point where there’s no more runtime errors, but it’s still not >>> working and I’m pretty sure it’s because I missed some typing. >>> >>> Is there any way to keep public accessors on one library or specific >>> classes? I’d like to compile my app with: >>> >>> "-js-dynamic-access-unknown-members=true", >>> "-export-public-symbols=false", >>> "-prevent-rename-protected-symbols=false", >>> "-prevent-rename-public-symbols=false", >>> "-prevent-rename-internal-symbols=false" >>> >>> but be able to exclude a list of classes from that. >>> >>>> On Dec 1, 2021, at 7:47 PM, Harbs <[email protected] >>>> <mailto:[email protected]> <mailto:[email protected] >>>> <mailto:[email protected]>>> wrote: >>>> >>>> I’m pretty sure the issue is related to events not being properly handled. >>>> Although blinding might be worth looking into. >>>> >>>> I’ll look into it some more when I have more time. >>>> >>>> Thanks! >>>> >>>>> On Dec 1, 2021, at 7:14 PM, Josh Tynjala <[email protected] >>>>> <mailto:[email protected]> <mailto:[email protected] >>>>> <mailto:[email protected]>>> wrote: >>>>> >>>>>> It *almost* works. I found and fixed two cases of bracket access which >>>>> broke things. Now I’m getting no errors, but it’s still not quite working. >>>>> I’m guessing it’s something simple that I need to fix. >>>>> >>>>> Have you tried a smaller set of prevent-rename options? That might help >>>>> you >>>>> narrow things down, if things start working better. I'd try allowing >>>>> public >>>>> variables, and maybe public accessors, to be renamed first, and see if >>>>> that >>>>> works. Those types of symbols are most likely to be getting accessed >>>>> dynamically somehow. However, I don't really have much in the way of tips >>>>> to narrow it down from there. ConstantBinding would be one thing to look >>>>> out for, which I mentioned in my summary. >
