And after thinking about it a bit more, I would recommend starting with #2 first so the stitching in of the semantic checks to the emitters in #1 might be simplified. If you look at BinaryOperatorEmitter for example, there are lots of if/else statements in there that might go away if there is context leading to better flow and fewer places to have to call semantic checks.
My 2 cents, -Alex On 6/14/19, 11:33 PM, "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 > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> > >> > >> > >> > >
