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> 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> 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.
