Just a quick followup to Harbs' earlier comment about the compiler noise. I'm seeing this a lot also.
It looks like there is some leftover diagnostic logging in ControlFlowGraph.traverseGraph. Hopefully it can be removed or dialed down. On Mon, Jul 1, 2019 at 7:06 AM Yishay Weiss <[email protected]> wrote: > 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 > > > > > > >>>>>>>>>> > > > > > > >>>>>>>>> > > > > > > >>>>>>>>> > > > > > > >>>>>>>> > > > > > > >>>>>>> > > > > > > >>>>>> > > > > > > >>>>> > > > > > > >>>>> > > > > > > >>>>> > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> > > > > > > >>> > > > > > > >>> > > > > > > >>> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
