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 <harbs.li...@gmail.com> 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 <yishayj...@hotmail.com 
>> <mailto:yishayj...@hotmail.com>> 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:harbs.li...@gmail.com <mailto:harbs.li...@gmail.com>>
>> Sent: Tuesday, December 28, 2021 11:36 PM
>> To: Apache Royale Development<mailto:dev@royale.apache.org 
>> <mailto:dev@royale.apache.org>>
>> 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 <harbs.li...@gmail.com 
>>> <mailto:harbs.li...@gmail.com>> 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 <harbs.li...@gmail.com 
>>>> <mailto:harbs.li...@gmail.com> <mailto:harbs.li...@gmail.com 
>>>> <mailto:harbs.li...@gmail.com>>> 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 <joshtynj...@bowlerhat.dev 
>>>>> <mailto:joshtynj...@bowlerhat.dev> <mailto:joshtynj...@bowlerhat.dev 
>>>>> <mailto:joshtynj...@bowlerhat.dev>>> 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.
> 

Reply via email to