I was also getting it before. ________________________________ From: Josh Tynjala <[email protected]> Sent: Sunday, June 30, 2019 3:53:56 PM To: [email protected] Subject: Re: Compiler Performance (was Re: Problem with Vectors)
Is this GC limit error something new? Or were you getting it before too? - Josh On Sun, Jun 30, 2019, 1:35 AM Yishay Weiss <[email protected]> wrote: > On my windows/powershell env there’s a significant improvement (~34 > seconds instead of ~42) when building our app with verbose switched off. > I’m getting a ‘GC overhead limit exceeded’ [1] error though quite often > which brings it up to around a minute and a half. Increasing heap size by > setting ANT_OPTS to -Xmx2g doesn’t seem to make a difference. > > > > [1] https://paste.apache.org/BXf4 > > > > ________________________________ > From: Josh Tynjala <[email protected]> > Sent: Friday, June 28, 2019 6:24:10 PM > To: [email protected] > Subject: Re: Compiler Performance (was Re: Problem with Vectors) > > Windows and PowerShell. > > I have not been cleaning bin/js-debug before each build. So my reported > times are more like what an app developer would experience most of the > time. Writing files after remove circulars still has an impact in that > situation. It's not huge, but still enough to be worth the effort, I think. > > Another thing I've noticed is that the compiler will randomly decide to do > a release build every now and then, even though I've always asked for debug > builds. Maybe a threading issue or something while the configuration one of > being initialized? > > - Josh > > On Thu, Jun 27, 2019, 9:35 PM Alex Harui <[email protected]> wrote: > > > Good progress! Are these times based on Windows? PowerShell? Mac? I'm > > just wondering if the Java code outputting strings is slow or the console > > saving the output or both. > > > > Are you only testing from a clean bin/js-debug? I thought that the > > compiler did not copy JS files that were already in bin/js-debug and > > remove-circulars re-uses those JS files. > > > > In theory, those of us modifying framework code have to clean out > > bin/js-debug more often than app developers. > > > > HTH, > > -Alex > > > > On 6/27/19, 4:00 PM, "Josh Tynjala" <[email protected]> wrote: > > > > I made a few smaller optimizations today. It seems to shave off about > > 0.4 > > to 0.5 seconds from the time to compile TourDeJewel on my computer. > > Not as > > dramatic as the last one, but still a measurable difference! > > > > I'd like to find a way to make remove-circulars happen earlier in the > > process. It takes files that are already written to the file system > and > > then modifies them. The extra re-write to disk is pretty expensive. > If > > all > > JS files were written to disk only once, we'd save another half > second > > or > > more. > > > > -- > > Josh Tynjala > > Bowler Hat LLC < > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbowlerhat.dev&data=02%7C01%7Caharui%40adobe.com%7C3763ea8f30394ff716bd08d6fb534693%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636972732457464401&sdata=SxYcGgMT3qQi2zEaeJAPA0AYm2UnB7Ljm4PvE4b3A4c%3D&reserved=0 > > > > > > > > > On Wed, Jun 26, 2019 at 2:42 PM Josh Tynjala <[email protected] > > > > wrote: > > > > > I found some low-hanging fruit! > > > > > > I just pushed a commit that removes most of the noisy console > output > > from > > > the compiler. I know that this output is useful for debugging the > > compiler > > > itself, but most developers writing ActionScript and MXML don't > ever > > need > > > to see it. > > > > > > If you actually want to see all of that output, you should now > > enable the > > > -verbose compiler option. > > > > > > With -verbose=true, TourDeJewel compiles in about 8 seconds on my > > machine. > > > With -verbose=false, it compiles in 6 seconds. We're talking about > > 20-25% > > > improvement to compile time for that particular project. I tested a > > smaller > > > project that is closer to a Hello World. It originally compiled in > > about > > > 4.3 seconds, and after my change the total time was reduced to > about > > 3.3 > > > seconds instead. > > > > > > If you're modifying the compiler in the future, and you want to > add a > > > System.out.println() call, make sure that it's only displayed in > > verbose > > > mode (unless it's related to an error, but then you might want > > > System.err.println() instead). You can check the isVerbose() method > > in the > > > project's Configuration object. > > > > > > - Josh > > > > > > On 2019/06/15 06:32:52, Alex Harui <[email protected]> > wrote: > > > > Just off the top of my head in my chat with Harbs last night, the > > two > > > biggest pieces of fruit are not low hanging, but honestly, I think > > you'd do > > > a better job of picking those off than I would. The two pieces of > > fruit > > > are: > > > > > > > > 1) Getting rid of the two tree walks per AS file: JS output > > currently > > > requires both the top-down AST walk (BlockWalker/Emitters) and a > > bottom-up > > > AST walk (CmcEmitter/JBurg/BURM). It seems intuitive that walking > > the tree > > > once would increase performance. The catch is that there are > > currently > > > no/few semantic checks in the BlockWalker/Emitters walk so all of > the > > > semantic checks from the BURM would have to be stitched into the > > Emitters > > > so it probably won't be twice as fast, and I believe there won't be > > one > > > place to stitch the BURM's calls into the semantic checks ino the > > > BlockWalker/Emitters. AIUI, the advantage of the BURM is it can > > "quickly" > > > identify patterns at the leaves where it affects the output. The > > > BlockWalker/Emitters might find that they need to ask the semantics > > of a > > > pattern near the leaves from several different emitters. > > > > > > > > 2) Experimenting with adding context data structures to the > > > BlockWalker/Emitters: Try single stepping through some medium > > complexity > > > AS code in the BlockWalker/Emitter part of the compiler. When I do > > so, I > > > think I see the same question being asked over and over again, such > > as > > > resolving an identifier, or checking if the parent node is a > > > MemberAccessExpression and more. I believe that caching > information > > in a > > > data structure passed down through the emitters would > significantly > > reduce > > > the number of questions asked and thus speed things up. Naturally, > > caching > > > more stuff will introduce caching bugs, but I expect it would > > eventually > > > pay off. I do worry about some issues around ActionScript and > > > "late-binding" (which is not the related to data-binding) and that > > caching > > > will screw that up. > > > > > > > > Smaller, potentially interesting projects include playing around > > with > > > subsetting AS. I believe there are parts of AS that require > > late-binding > > > and scopes and other stuff that may not exist on other runtimes, > and > > it is > > > possible that by warning when those parts of AS are used (custom > > > namespaces, for example), then if folks write their code without > > custom > > > namespaces they could get a significant compiler speed increase > > because the > > > compiler doesn't have to worry about late-binding. The interesting > > result > > > of doing this may be better options for outputting WASM, Java, C, > > and other > > > stricter languages. > > > > > > > > There is also a potentially interesting task around combining, > for > > > example, Basic.swc and BasicJS.swc into one multi-platform SWC. > > That would > > > save time on compiling the entire framework, but would require > > tooling > > > changes and build script changes. The advantage is that it would > > only > > > transpile AS to JS once. Right now, the transpile is run once for > > > Basic.swc and again for BasicJS.swc. It could be possible to steal > > the > > > already transpiled JS from Basic.swc. Or maybe the copying of the > > JS files > > > will still be a performance bottleneck. The advantage is also that > > there > > > is only one SWC to deploy instead of two which might simplify Maven > > as well. > > > > > > > > HTH, > > > > -Alex > > > > > > > > > > > > > > > > > > > > On 6/14/19, 7:11 PM, "Josh Tynjala" <[email protected]> > > wrote: > > > > > > > > Understood. I'll switch my focus and see if I can find some > low > > > hanging fruit. > > > > > > > > - Josh > > > > > > > > On 2019/06/15 01:51:48, Harbs <[email protected]> wrote: > > > > > I had a long discussion with Alex last night (sorry you > > couldn’t > > > make it!) and he convinced me of the necessity of caution in regard > > to > > > adding these language features. Waiting until we get the input of a > > > language specialist is prudent. > > > > > > > > > > I do want those features, but we do need to figure out how > > they > > > fit into a bigger picture of generics and the like. I’d like to > > brainstorm > > > on how we can get a language specialist involved enough to at least > > guide > > > us here. > > > > > > > > > > In discussing with Alex what’s the best avenue for > improving > > the > > > compiler in the short term, the topic of performance came up. > That’s > > been > > > somewhat of a pain point and working on that is probably a good > idea. > > > > > > > > > > Harbs > > > > > > > > > > > On Jun 14, 2019, at 2:11 PM, Josh Tynjala < > > > [email protected]> wrote: > > > > > > > > > > > > I asked because I don't understand your question either. > > > > > > > > > > > > Harbs wants something similar to a Vector, with two > > important > > > features. > > > > > > > > > > > > 1) No runtime type checking. > > > > > > 2) It should also be able to convert to and from an > untyped > > > Array with some kind of simple cast at compile-time. At runtime, it > > is just > > > an untyped Array. > > > > > > > > > > > > I don't see how Uint8Array can work for this. As I > > understand > > > it, Uint8Array seems to be numeric only and isn't actually the same > > as an > > > Array. > > > > > > > > > > > > I should probably just leave it to him to explain, > though. > > It's > > > his vision, and I'm just the guy implementing it for him. > > > > > > > > > > > > - Josh > > > > > > > > > > > > On 2019/06/14 20:58:34, Alex Harui > > <[email protected]> > > > wrote: > > > > > >> I'm not sure I understand the question. I suspect it > > would be > > > up to the implementors of a typed array implementation to decide. > > There > > > may not be one solution that works for everyone. The compiler > could > > > disallow it, or the implementation could AMF encode the instance, > or > > the > > > implementation could throw an error. > > > > > >> > > > > > >> -Alex > > > > > >> > > > > > >> On 6/14/19, 1:53 PM, "Josh Tynjala" < > > [email protected]> > > > wrote: > > > > > >> > > > > > >> How do you store a String, or any random class, in > > > Uint8Array? > > > > > >> > > > > > >> - Josh > > > > > >> > > > > > >> On 2019/06/14 20:31:28, Alex Harui > > <[email protected]> > > > wrote: > > > > > >>> IMO, I would not expect the edge cases around > "abstract" > > and > > > "private" to impact future language features as those are only > > allowed as > > > "decorators" on definitions and those features, from a language > > standpoint, > > > allowed new keywords where the grammar already allowed keywords. > > > > > >>> > > > > > >>> My concern around proposals for TypedArrays such as > > > Array.<int> or int[] are that those patterns can show up in a lot > > more > > > places and if we don't pick the right syntax, we'll be sorry later > > when we > > > try to do typed function signatures or generics or something else. > > AIUI, > > > you have to think through where else ".", "<", ">", "[" and "]" are > > used in > > > the language and make sure your new use for them won't cause > > conflicts now, > > > or even worse, in the future. And consider the general usability > and > > > coercion rules and probably other things that I don't even know to > > consider > > > since I am not a language designer. Sure, Vector already uses > > ".<>", but > > > it appears those uses are mapped to a special construct in the > > compiler, > > > and that's why my suggestions for TypedArrays try to provide > > directives for > > > the output of that construct instead of adding a new construct > until > > we are > > > sure that other future plans won't be compromised by how we support > > > TypedArrays now. > > > > > >>> > > > > > >>> For example, the name Vector implies one-dimension to > > me. But > > > I could imagine folks wanting to add support for multi-dimensional > > Arrays. > > > Or the equivalent of Java Maps. > > > > > >>> > > > > > >>> Or, what will be the proposed literal for Typed Arrays > > if you > > > use Array.<int>? Will it be the same or different from Vector > > literal? > > > > > >>> > > > > > >>> For sure, I don't think there is anybody active in the > > project > > > who is opposed to supporting new language features like generics, > > typed > > > functions and typed arrays. I'm just asking questions to make sure > > we > > > really need this work done now instead of doing something cheaper > > and make > > > sure folks who do work on it think through the future implications > > of it. > > > > > >>> > > > > > >>> We already use directives to make "promises". For > > example, > > > when you use @royaleignorecoercion, you promise that no code paths > > will > > > actually depend on that coercion, you just added the coercion to > > keep the > > > compiler from complaining. And if it turns out you needed it, > > you'll end > > > up with a bug. We could do something similar now like > > > @royaleusetypedarrayforthisvector and if other code ends up turning > > off the > > > "fixed" property and push stuff you'll end up with a bug. I think > > that > > > would only take someone a week or less. > > > > > >>> > > > > > >>> Or as I asked earlier, why can't folks just use > > Uint8Array? > > > > > >>> > > > > > >>> HTH, > > > > > >>> -Alex > > > > > >>> > > > > > >>> On 6/14/19, 11:08 AM, "Josh Tynjala" < > > [email protected]> > > > wrote: > > > > > >>> > > > > > >>> I definitely understand your concern about > potentially > > > missing edge cases, and having that cause problems in the future. > > That's > > > why I've been trying to make new language features disabled by > > default so > > > that folks need to knowingly opt in. > > > > > >>> > > > > > >>> In my opinion, we should have left abstract classes > > and > > > private constructors disabled by default for a while, until more > > people > > > could give them a try. These features haven't even been included in > > an > > > official release yet. While I have a pretty good set of unit tests > > for each > > > one, I'm sure that there are still some edge cases that I'll need > to > > > address in the future. > > > > > >>> > > > > > >>> - Josh > > > > > >>> > > > > > >>> > > > > > >>> On 2019/06/14 17:39:53, Alex Harui > > <[email protected]> > > > wrote: > > > > > >>>> IMO, it will be a significant amount of work to > provide > > new > > > syntax around typed collections to ActionScript. I cannot help > here > > > because I am not a language expert. Having interacted briefly with > > the > > > ActionScript language team, I am certain I do not have the skills > to > > help > > > here and am concerned that we'll miss something and be sorry later. > > > > > >>>> > > > > > >>>> So, as long as folks are aware of that and still want > > to go > > > forward, I'm not going to stand in their way. I am going to > suggest > > easier > > > ways that might save some time because I think there are bigger > fish > > to fry > > > with the limited folks we have contributing to Royale. I'd rather > > see a > > > quick way of allowing folks to use TypedArrays to see how > > useful/important > > > it is and then see if we can make Royale successful and recruit > > someone > > > with language design experience. > > > > > >>>> > > > > > >>>> IOW, creating the general case implementation starting > > now > > > may not be in the best interests of the project. I would rather we > > make > > > migrating Flex code easier/faster, and those folks may not have > time > > to > > > consider changing their code to switch to TypedArrays. > > > > > >>>> > > > > > >>>> Just from some quick thinking, I would say that > getting > > the > > > parser to handle some new syntax is only 25% of the work. Another > > 10% is > > > in getting the output right for JS, but the remaining 65% is > handling > > > semantics, ambiguity, and output to other runtimes. > > > > > >>>> > > > > > >>>> Also, since Array is "final", I think it would be more > > work > > > to support Array.<int> than TypedArray.<int>. And probably even > > easier > > > just to support the exact same classnames and APIs that JavaScript > > supports > > > today. Is there some reason that Uint8Array doesn't work today? > > > > > >>>> > > > > > >>>> I'd prefer that we take the time to find an expert to > > help us > > > really think through how we will implement generics in general in > AS > > > someday, and handle Typed Arrays as an initial implementation on > > that path > > > so we don't later go "oh crap, if we hadn't picked this particular > > syntax > > > for typed arrays, our generics support would be so much simpler!". > > I just > > > know I cannot help here, but I caution against just copying what > > Java or > > > Typescript does. I think there are patterns in ActionScript that > are > > > different from Java and TS that might factor in. > > > > > >>>> > > > > > >>>> So, go for it if you want, but please consider future > > > ramifications. > > > > > >>>> > > > > > >>>> -Alex > > > > > >>>> > > > > > >>>> On 6/12/19, 5:20 PM, "Greg Dove" <[email protected] > > > > wrote: > > > > > >>>> > > > > > >>>> Alex, javascript TypeArrays are fixed length at > > > construction, so I really > > > > > >>>> don't think that can work in general case for > drop-in > > > substitution of > > > > > >>>> numeric Vector without some sort of wrapper class > > that > > > supports swapping > > > > > >>>> things out. > > > > > >>>> I really think that dedicated 'fast' numeric > > collection > > > types will likely > > > > > >>>> need their own cross-target classes. > > > > > >>>> It would work for a Vector that has a fixed = true > > > constructor arg and then > > > > > >>>> never changes its 'fixed' status (and therefore > never > > > changes its length > > > > > >>>> also) and also only uses index access and > > assignments (no > > > push, pop etc), > > > > > >>>> but it's a pretty restrictive scenario. I did look > > at this > > > already. > > > > > >>>> It might also be possible to map default Vector > > numeric > > > types to 'faster' > > > > > >>>> versions for the 3 types, as an opt-in to the > default > > > implementation's > > > > > >>>> approach. I do plan to work on/investigate this > > later this > > > month, because I > > > > > >>>> am keen to see performance-oriented options here > > too. But > > > I was thinking > > > > > >>>> they would likely be separate, dedicated classes. > > > > > >>>> > > > > > >>>> > > > > > >>>> On Thu, Jun 13, 2019 at 11:27 AM Alex Harui > > > <[email protected]> > > > > > >>>> wrote: > > > > > >>>> > > > > > >>>>> FWIW, I would expect any syntax changes to be a > > significant > > > amount of work > > > > > >>>>> especially where the BURM does the semantic checks. > > New > > > BURM patterns are > > > > > >>>>> probably required. Or maybe it is time to get the > > BURM out > > > of the > > > > > >>>>> semantic-check business for JS (and maybe SWF) output > > and > > > figure out how to > > > > > >>>>> do the semantic checks from the JS AST walk. > > > > > >>>>> > > > > > >>>>> Did you out finding a way to indicate that some > > Vector.<int> > > > should be > > > > > >>>>> implemented as a TypedArray? > > > > > >>>>> > > > > > >>>>> -Alex > > > > > >>>>> > > > > > >>>>> On 6/12/19, 3:18 PM, "Josh Tynjala" < > > [email protected]> > > > wrote: > > > > > >>>>> > > > > > >>>>> I plan to start out by supporting Array.<T> > syntax, > > > similar to > > > > > >>>>> Vector.<T>. Like you said, there are advantages to > > using the > > > same syntax > > > > > >>>>> for all typed collections. > > > > > >>>>> > > > > > >>>>> Later, I'll see if I can figure out how to add T[] > > syntax > > > as an > > > > > >>>>> alternative, since Harbs seems to like that better. > > > > > >>>>> > > > > > >>>>> - Josh > > > > > >>>>> > > > > > >>>>> On 2019/06/12 20:14:50, Greg Dove < > > [email protected]> > > > wrote: > > > > > >>>>>> Hey Josh, > > > > > >>>>>> > > > > > >>>>>> Thanks for looking into that, I figured it could be > a > > bit > > > tricky! > > > > > >>>>> Good luck > > > > > >>>>>> with it. > > > > > >>>>>> I think you and Harbs were maybe leaning to towards > > > Number[] and > > > > > >>>>> String[] > > > > > >>>>>> type declarations. I don't mind either way, but > > perhaps the > > > Array. > > > > > >>>>> with > > > > > >>>>>> angle brackets approach that is used for Vectors > > could make > > > it > > > > > >>>>> easier to > > > > > >>>>>> swap between typed Array and Vector if people > consider > > > refactoring > > > > > >>>>> (and > > > > > >>>>>> whatever IDE they're using won't support more > > automated > > > changes). > > > > > >>>>> OTOH, the > > > > > >>>>>> first approach is definitely easier to type. You > > probably > > > already > > > > > >>>>> thought > > > > > >>>>>> those things through though, I guess. > > > > > >>>>>> > > > > > >>>>>> If you end up with a remote branch for your work on > > this at > > > some > > > > > >>>>> point and > > > > > >>>>>> want someone to help with testing or anything like > > that, > > > I'm in, > > > > > >>>>> just let > > > > > >>>>>> me know. > > > > > >>>>>> > > > > > >>>>>> > > > > > >>>>>> On Thu, Jun 13, 2019 at 2:26 AM Josh Tynjala < > > > [email protected]> > > > > > >>>>> wrote: > > > > > >>>>>> > > > > > >>>>>>>> I think your other proposal with Josh for the > typed > > > Arrays and > > > > > >>>>> their > > > > > >>>>>>> greater compile-time safety will be a better fit > for > > many > > > cases as > > > > > >>>>> well, so > > > > > >>>>>>> I hope that happens. > > > > > >>>>>>> > > > > > >>>>>>> I started working on typed arrays this week. It may > > be a > > > while > > > > > >>>>> before I > > > > > >>>>>>> can merge, though. It's definitely more complex > than > > > private > > > > > >>>>> constructors > > > > > >>>>>>> and abstract classes. > > > > > >>>>>>> > > > > > >>>>>>> - Josh > > > > > >>>>>>> > > > > > >>>>>>> On 2019/06/12 04:21:18, Greg Dove < > > [email protected]> > > > wrote: > > > > > >>>>>>>> Hi Harbs - just in reply to your specific > questions: > > > > > >>>>>>>> As I mentioned elsewhere it is easy to have full > > speed > > > index > > > > > >>>>> access and > > > > > >>>>>>>> also full speed pop() and unshift() methods > > > > > >>>>>>>> If you switch off the first 3 settings I outlined > > in the > > > post > > > > > >>>>> titled > > > > > >>>>>>>> 'Language/Reflection improvements details' you > will > > have > > > that. > > > > > >>>>> Those > > > > > >>>>>>>> settings are switchable locally with doc > directives > > as > > > well. I > > > > > >>>>> will do a > > > > > >>>>>>>> full write-up this coming weekend for docs. > > Hopefully I > > > can > > > > > >>>>> harvest a lot > > > > > >>>>>>>> of what I already wrote elsewhere for that. > > > > > >>>>>>>> BTW I switched TLF to use the legacy > Vector-as-Array > > > approach by > > > > > >>>>>>> default, I > > > > > >>>>>>>> am not sure what you want there, you could undo > > that if > > > you > > > > > >>>>> prefer. > > > > > >>>>>>>> > > > > > >>>>>>>> Beyond the above mentioned approaches for (mainly > > index > > > level) > > > > > >>>>>>>> optimization, I have a preference for two more > > > approaches, but > > > > > >>>>> I'd rather > > > > > >>>>>>>> limit the overall number of options to be what > > people > > > definitely > > > > > >>>>> need > > > > > >>>>>>>> instead of adding too many options (which could > > create > > > > > >>>>> confusion). I > > > > > >>>>>>> think > > > > > >>>>>>>> your other proposal with Josh for the typed Arrays > > and > > > their > > > > > >>>>> greater > > > > > >>>>>>>> compile-time safety will be a better fit for many > > cases > > > as well, > > > > > >>>>> so I > > > > > >>>>>>> hope > > > > > >>>>>>>> that happens. If I have time to help out in any > way > > with > > > that, I > > > > > >>>>> would be > > > > > >>>>>>>> happy to do so as well, because it sounds like > > something > > > I would > > > > > >>>>> use a > > > > > >>>>>>> lot. > > > > > >>>>>>>> Anyhow, I do want to support more optimizations > > with this > > > > > >>>>> implementation. > > > > > >>>>>>>> Can you say what your main concerns would be for > > > optimization? > > > > > >>>>> Is it > > > > > >>>>>>> mainly > > > > > >>>>>>>> for 'push' (and unshift) ? Those would be mine... > > > > > >>>>>>>> > > > > > >>>>>>>> I would personally like to see the following: > > > > > >>>>>>>> > > > > > >>>>>>>> 1. A global optimization setting that affects all > > > instances in > > > > > >>>>> all code > > > > > >>>>>>>> including pre-built library code. This would avoid > > certain > > > > > >>>>> runtime checks > > > > > >>>>>>>> and would also result in a lighter implementation. > > This is > > > > > >>>>> something the > > > > > >>>>>>>> final application developer decides, not anything > > > dictated by a > > > > > >>>>> library > > > > > >>>>>>>> developer (but a library developer could advertise > > their > > > public > > > > > >>>>> swc as > > > > > >>>>>>>> being compatible/safe with this type of > > optimization). > > > This > > > > > >>>>> approach > > > > > >>>>>>> could > > > > > >>>>>>>> include perhaps 2 levels: one to remove any code > > paths > > > related > > > > > >>>>> to fixed > > > > > >>>>>>>> length Vectors (which I think you said you never > > used) for > > > > > >>>>> example. Then > > > > > >>>>>>>> another possibly removing all element level > > type-checking > > > as > > > > > >>>>> another > > > > > >>>>>>> level. > > > > > >>>>>>>> Adding this should not be too difficult I think > and > > would > > > be > > > > > >>>>> determined > > > > > >>>>>>> via > > > > > >>>>>>>> a goog define (which might be driven by a compiler > > > setting, I > > > > > >>>>> did not > > > > > >>>>>>> look > > > > > >>>>>>>> at how easy this is yet). The thing I like about > > this > > > approach > > > > > >>>>> is that it > > > > > >>>>>>>> is not 'baked-in' to any instance and the > > application > > > developer > > > > > >>>>> makes the > > > > > >>>>>>>> ultimate decision and owns the associated risk (as > > > opposed to > > > > > >>>>> having it > > > > > >>>>>>>> imposed on them by a library developer, for > > example). I > > > think > > > > > >>>>> the removal > > > > > >>>>>>>> of support for 'fixed' Vectors could probably be > > made to > > > generate > > > > > >>>>>>>> (debug-only) errors if there is code that runs > that > > sets > > > fixed > > > > > >>>>> to true on > > > > > >>>>>>>> any Vector instance - to provide some reassurance > > of no > > > side > > > > > >>>>> effects > > > > > >>>>>>> when > > > > > >>>>>>>> choosing this option. > > > > > >>>>>>>> > > > > > >>>>>>>> 2. Compilation scoped optimizations. > > > > > >>>>>>>> By 'compilation-scoped' I mean configurable in the > > same > > > way as > > > > > >>>>> the > > > > > >>>>>>>> vector-index-check suppression: An over-arching > > config > > > setting > > > > > >>>>> for the > > > > > >>>>>>>> current compilation that can be overridden locally > > with > > > doc > > > > > >>>>> comment > > > > > >>>>>>>> directives. This affects code sites (or all > current > > > compilation > > > > > >>>>> scope if > > > > > >>>>>>>> set in the config) and not specific instances. I > > would > > > hope this > > > > > >>>>> might be > > > > > >>>>>>>> the only other 'Vector' specific config option > like > > this, > > > simply > > > > > >>>>> to avoid > > > > > >>>>>>>> confusion with too many options. > > > > > >>>>>>>> So I personally think the important things here > are > > the > > > push and > > > > > >>>>> unshift > > > > > >>>>>>>> methods, because they're the ones that are also > most > > > often used > > > > > >>>>> in loops > > > > > >>>>>>>> when index level access or assignment is not being > > used > > > (in the > > > > > >>>>> loop). > > > > > >>>>>>> But > > > > > >>>>>>>> I'm keen to hear more about what people want in > > case it's > > > > > >>>>> different to > > > > > >>>>>>> how > > > > > >>>>>>>> I think. And I will add support for what best > > represents > > > the > > > > > >>>>> needs of the > > > > > >>>>>>>> community. While index level access is best for > > large > > > loops > > > > > >>>>> (just as it > > > > > >>>>>>> is > > > > > >>>>>>>> for 'Array'), push could be preferred in small > loops > > > because it > > > > > >>>>> does not > > > > > >>>>>>>> require a 'get' for length to establish the upper > > bound > > > of the > > > > > >>>>> loop or > > > > > >>>>>>> the > > > > > >>>>>>>> next acceptable index to set (for non-fixed > > Vectors). The > > > > > >>>>> optimization > > > > > >>>>>>> for > > > > > >>>>>>>> push in this case would be to bypass runtime > > typechecking > > > and > > > > > >>>>> just do a > > > > > >>>>>>>> regular Array.push into the underlying Vector > > > representation, > > > > > >>>>> which is > > > > > >>>>>>>> still actually an Array in terms of how javascript > > sees > > > it. > > > > > >>>>> Adding this > > > > > >>>>>>>> option is easy also, but rather than just forging > > ahead > > > with it, > > > > > >>>>> I am > > > > > >>>>>>> keen > > > > > >>>>>>>> to get input from others first. > > > > > >>>>>>>> > > > > > >>>>>>>> I consider that specific instance level > > optimizations (in > > > > > >>>>> general) are > > > > > >>>>>>>> 'dangerous' because even if the code is 'safe' > when > > it is > > > > > >>>>> originally > > > > > >>>>>>>> written, subsequent changes to the overall > codebase > > > (possibly by > > > > > >>>>>>> different > > > > > >>>>>>>> developers) can mean that an instance ends up > > elsewhere > > > in code > > > > > >>>>> where it > > > > > >>>>>>>> behaves differently from other instances of the > > same type. > > > > > >>>>> Code-site > > > > > >>>>>>>> optimizations could also create an unusual > internal > > state > > > for an > > > > > >>>>>>> instance, > > > > > >>>>>>>> but most often they should not, because the code > > site > > > where the > > > > > >>>>>>>> optimization is used should be validated in terms > > of the > > > > > >>>>> optimization by > > > > > >>>>>>>> its original developer (e.g. no runtime type > > checking at a > > > > > >>>>> particular > > > > > >>>>>>> usage > > > > > >>>>>>>> site because it is never needed in the context of > > that > > > code, for > > > > > >>>>> example) > > > > > >>>>>>>> and the behavior of the same instance elsewhere > > should be > > > much > > > > > >>>>> less of a > > > > > >>>>>>>> risk. > > > > > >>>>>>>> > > > > > >>>>>>>> More feedback from you or anyone else is > definitely > > > welcome for > > > > > >>>>> what they > > > > > >>>>>>>> want to see for optimization options of the > > > implementation. I'm > > > > > >>>>> sure I > > > > > >>>>>>> can > > > > > >>>>>>>> still find more ways to improve the implementation > > for > > > speed as > > > > > >>>>> it is now > > > > > >>>>>>>> as well, I can think of a one thing I want to > > investigate > > > > > >>>>> further. > > > > > >>>>>>>> -Greg > > > > > >>>>>>>> > > > > > >>>>>>>> > > > > > >>>>>>>> > > > > > >>>>>>>> > > > > > >>>>>>>> On Wed, Jun 12, 2019 at 1:54 AM Harbs < > > > [email protected]> > > > > > >>>>> wrote: > > > > > >>>>>>>> > > > > > >>>>>>>>> Practical question for me is: How do we disable > to > > Vector > > > > > >>>>> runtime > > > > > >>>>>>>>> checking? I was having trouble following the full > > > discussion. > > > > > >>>>> My > > > > > >>>>>>>>> understanding was that there’s a compiler flag, > > but I’m > > > not > > > > > >>>>> sure what > > > > > >>>>>>> it is. > > > > > >>>>>>>>> > > > > > >>>>>>>>>> On Jun 11, 2019, at 7:10 AM, Yishay Weiss < > > > > > >>>>> [email protected]> > > > > > >>>>>>>>> wrote: > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> Language.js:868 [1] is > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> if (elementType.indexOf('Vector.<') == 0) { > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> ________________________________ > > > > > >>>>>>>>>> From: Yishay Weiss <[email protected]> > > > > > >>>>>>>>>> Sent: Tuesday, June 11, 2019 2:07:36 PM > > > > > >>>>>>>>>> To: [email protected] > > > > > >>>>>>>>>> Subject: Problem with Vectors > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> Hi Greg, > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> I just updated Royale and I’m seeing that in our > > class > > > > > >>>>> FontLoader > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> private var _fonts:Vector.<Font> = new > > Vector.<Font>(); > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> gets transpiled to > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> this.com_printui_text_engine_FontLoader__fonts = > > > > > >>>>>>>>> org.apache.royale.utils.Language.Vector(); > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> Notice how the type isn’t given in Vector’s > > > constructor. This > > > > > >>>>>>> results in > > > > > >>>>>>>>> a runtime error [1]. Any ideas? > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> [1] > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> TypeError: Cannot read property 'indexOf' of > null > > > > > >>>>>>>>>> Watch > > > > > >>>>>>>>>> Call Stack > > > > > >>>>>>>>>> > > > > > >>>>> > > > > org.apache.royale.utils.Language.VectorSupport.vectorElementCoercion > > > > > >>>>>>>>>> Language.js:868 > > > > > >>>>>>>>>> org.apache.royale.utils.Language.synthVector > > > > > >>>>>>>>>> Language.js:642 > > > > > >>>>>>>>>> org.apache.royale.utils.Language.Vector > > > > > >>>>>>>>>> Language.js:685 > > > > > >>>>>>>>>> com.printui.text.engine.FontLoader > > > > > >>>>>>>>>> FontLoader.js:24 > > > > > >>>>>>>>>> > > > > > >>>>>>>>> > > > > > >>>>>>>>> > > > > > >>>>>>>> > > > > > >>>>>>> > > > > > >>>>>> > > > > > >>>>> > > > > > >>>>> > > > > > >>>>> > > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >> > > > > > >> > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
