I should have drawn attention to this again before release work started... I guess it is too late to get rid of that diagnostic output (described below) from the compiler in the release? It might be confusing output for some people, or create the wrong impression, but perhaps it is too late in the process?
On Wed, Jul 3, 2019 at 8:42 PM Greg Dove <[email protected]> wrote: > > 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 >> > > > > > >>>>>>>>>> >> > > > > > >>>>>>>>> >> > > > > > >>>>>>>>> >> > > > > > >>>>>>>> >> > > > > > >>>>>>> >> > > > > > >>>>>> >> > > > > > >>>>> >> > > > > > >>>>> >> > > > > > >>>>> >> > > > > > >>>> >> > > > > > >>>> >> > > > > > >>>> >> > > > > > >>> >> > > > > > >>> >> > > > > > >>> >> > > > > > >> >> > > > > > >> >> > > > > > >> >> > > > > > >> > > > > > >> > > > > >> > > > > >> > > > > >> > > > >> > > >> > > >> > > >> > >> >
