I love this!!! thanks Harb Hiedra
-----Mensaje original----- De: Harbs <harbs.li...@gmail.com> Enviado el: miércoles, 29 de diciembre de 2021 12:11 Para: Apache Royale Development <dev@royale.apache.org> Asunto: Re: Compiler options for reducing release build size of Royale projects (Part 2) Done: https://apache.github.io/royale-docs/create-an-application/optimizations/minification > On Dec 29, 2021, at 8:11 AM, Harbs <harbs.li...@gmail.com> wrote: > > 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 >> <mailto: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. >> >
