Re: Compiler Performance (was Re: Problem with Vectors)

[Piotr Zarzycki]

Hi Greg,

Well I definitely in the very last steps, but if I won't be able to figure
out how to upload artifacts I'm not sure whether we will not stuck for the
next couple of weeks. :(

Thanks,
Piotr

On Wed, Aug 14, 2019, 9:50 PM Greg Dove  wrote:

> 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  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 
> > wrote:
> >
> >> I was also getting it before.
> >> ________
> >> From: Josh Tynjala 
> >> Sent: Sunday, June 30, 2019 3:53:56 PM
> >> To: dev@royale.apache.org
> >> 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 
> >> 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 
> >> > Sent: Friday, June 28, 2019 6:24:10 PM
> >> > To: dev@royale.apache.org
> >> > 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 
> >> 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" 
> >> 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

Re: Compiler Performance (was Re: Problem with Vectors)

[Greg Dove]

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  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 
> wrote:
>
>> I was also getting it before.
>> 
>> From: Josh Tynjala 
>> Sent: Sunday, June 30, 2019 3:53:56 PM
>> To: dev@royale.apache.org
>> 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 
>> 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 
>> > Sent: Friday, June 28, 2019 6:24:10 PM
>> > To: dev@royale.apache.org
>> > 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 
>> 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" 
>> 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%7Cfa7b1b5a

Re: Compiler Performance (was Re: Problem with Vectors)

[Greg Dove]

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  wrote:

> I was also getting it before.
> 
> From: Josh Tynjala 
> Sent: Sunday, June 30, 2019 3:53:56 PM
> To: dev@royale.apache.org
> 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  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 
> > Sent: Friday, June 28, 2019 6:24:10 PM
> > To: dev@royale.apache.org
> > 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 
> 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" 
> 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 <
> joshtynj...@apache.org
> > >
> > > 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.
> > > >
> > > 

Re: Compiler Performance (was Re: Problem with Vectors)

[Yishay Weiss]

I was also getting it before.

From: Josh Tynjala 
Sent: Sunday, June 30, 2019 3:53:56 PM
To: dev@royale.apache.org
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  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 
> Sent: Friday, June 28, 2019 6:24:10 PM
> To: dev@royale.apache.org
> 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  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"  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  >
> > 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 displ

Re: Compiler Performance (was Re: Problem with Vectors)

[Josh Tynjala]

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  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 
> Sent: Friday, June 28, 2019 6:24:10 PM
> To: dev@royale.apache.org
> 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  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"  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  >
> > 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 th

RE: Compiler Performance (was Re: Problem with Vectors)

[Yishay Weiss]

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 
Sent: Friday, June 28, 2019 6:24:10 PM
To: dev@royale.apache.org
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  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"  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 
> 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  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

Re: Compiler Performance (was Re: Problem with Vectors)

[Carlos Rovira]

Ok Alex, I'll do that as I find again the problem
thanks

El vie., 28 jun. 2019 a las 23:05, Alex Harui ()
escribió:

> Don't know if it is related.  If you get a failed build, copy the bin
> folder somewhere.  Then when you get a good build, run diff on the two
> folders.
>
> -Alex
>
> On 6/28/19, 11:30 AM, "Carlos Rovira"  wrote:
>
> One thing I notice while developing our Real App and with Tour De Flex
> was
> a situation where ramdomly the app makes a failed compilation. The
> results
> was all labels are empty, so for example in TDJ all options in the left
> menu are blank and icons are missing, since are test too. This use to
> happen 1/10 of times (in average), and seems to happen both in Mac and
> Windows. I don't remember if I reported this here or not. Was something
> really cumbersome and necessary to be fixed some time, but difficult to
> expose due to the random behavior that means anyone wanting to see this
> will need to take TDJ and compile until he sees the false positive.
>
> I always think this problem should be something related to a thread
> behavior problem.
>
> Maybe this issue and what Josh describe can be related?
>
> Thanks
>
>
>
>
> El vie., 28 jun. 2019 a las 19:05, Alex Harui
> ()
> escribió:
>
> >
> >
> > On 6/28/19, 8:24 AM, "Josh Tynjala" 
> wrote:
> >
> > Windows and PowerShell.
> >
> > I've noticed my windows builds (command prompt, not powershell) are
> > significantly slower than my Mac, but never investigated further.
> Maybe my
> > Mac has more or faster cores and memory.  But I've often wondered if
> the
> > many Windows virus checkers are a factor as well, especially those
> that
> > check on every disk write.
> >
> > 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.
> >
> > For some file in a framework swc like UIBase.js, it should not be
> written
> > to bin/js-debug/ on every compile.  The file is pulled from the SWC
> on a
> > "clean compile" and remove-circulars writes some information about
> the
> > dependency tree into that file.  On subsequent compiles, the
> > remove-circulars code should notice that information and read it and
> not
> > write UIBase.js again.
> >
> > It may be that some files must be rewritten to re-compute static
> > initialization order, but that should be a small fraction of the
> total set
> > of .js files.
> >
> > 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?
> >
> > I've never seen that.  Taking a quick peek at the code, I noticed
> that
> > MXMLRoyalePublisher is checking configuration.release() which sounds
> right,
> > but configuration.release() is actually checking an uninitialized
> boolean
> > (and probably the wrong one (it is checking verbosestacktraces
> instead of
> > generatedebugtags)).  I think in Java an uninitialized Boolean is
> false, so
> > that should still work correctly.
> >
> > HTH,
> > -Alex
> >
> > - Josh
> >
> > On Thu, Jun 27, 2019, 9:35 PM Alex Harui
> 
> > 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"  >
> > 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 t

Re: Compiler Performance (was Re: Problem with Vectors)

[Alex Harui]

Don't know if it is related.  If you get a failed build, copy the bin folder 
somewhere.  Then when you get a good build, run diff on the two folders.

-Alex

On 6/28/19, 11:30 AM, "Carlos Rovira"  wrote:

One thing I notice while developing our Real App and with Tour De Flex was
a situation where ramdomly the app makes a failed compilation. The results
was all labels are empty, so for example in TDJ all options in the left
menu are blank and icons are missing, since are test too. This use to
happen 1/10 of times (in average), and seems to happen both in Mac and
Windows. I don't remember if I reported this here or not. Was something
really cumbersome and necessary to be fixed some time, but difficult to
expose due to the random behavior that means anyone wanting to see this
will need to take TDJ and compile until he sees the false positive.

I always think this problem should be something related to a thread
behavior problem.

Maybe this issue and what Josh describe can be related?

Thanks




El vie., 28 jun. 2019 a las 19:05, Alex Harui ()
escribió:

>
>
> On 6/28/19, 8:24 AM, "Josh Tynjala"  wrote:
>
> Windows and PowerShell.
>
> I've noticed my windows builds (command prompt, not powershell) are
> significantly slower than my Mac, but never investigated further.  Maybe 
my
> Mac has more or faster cores and memory.  But I've often wondered if the
> many Windows virus checkers are a factor as well, especially those that
> check on every disk write.
>
> 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.
>
> For some file in a framework swc like UIBase.js, it should not be written
> to bin/js-debug/ on every compile.  The file is pulled from the SWC on a
> "clean compile" and remove-circulars writes some information about the
> dependency tree into that file.  On subsequent compiles, the
> remove-circulars code should notice that information and read it and not
> write UIBase.js again.
>
> It may be that some files must be rewritten to re-compute static
> initialization order, but that should be a small fraction of the total set
> of .js files.
>
> 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?
>
> I've never seen that.  Taking a quick peek at the code, I noticed that
> MXMLRoyalePublisher is checking configuration.release() which sounds 
right,
> but configuration.release() is actually checking an uninitialized boolean
> (and probably the wrong one (it is checking verbosestacktraces instead of
> generatedebugtags)).  I think in Java an uninitialized Boolean is false, 
so
> that should still work correctly.
>
> HTH,
> -Alex
>
> - Josh
>
> On Thu, Jun 27, 2019, 9:35 PM Alex Harui 
> 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" 
> 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 <
>

Re: Compiler Performance (was Re: Problem with Vectors)

[Carlos Rovira]

One thing I notice while developing our Real App and with Tour De Flex was
a situation where ramdomly the app makes a failed compilation. The results
was all labels are empty, so for example in TDJ all options in the left
menu are blank and icons are missing, since are test too. This use to
happen 1/10 of times (in average), and seems to happen both in Mac and
Windows. I don't remember if I reported this here or not. Was something
really cumbersome and necessary to be fixed some time, but difficult to
expose due to the random behavior that means anyone wanting to see this
will need to take TDJ and compile until he sees the false positive.

I always think this problem should be something related to a thread
behavior problem.

Maybe this issue and what Josh describe can be related?

Thanks




El vie., 28 jun. 2019 a las 19:05, Alex Harui ()
escribió:

>
>
> On 6/28/19, 8:24 AM, "Josh Tynjala"  wrote:
>
> Windows and PowerShell.
>
> I've noticed my windows builds (command prompt, not powershell) are
> significantly slower than my Mac, but never investigated further.  Maybe my
> Mac has more or faster cores and memory.  But I've often wondered if the
> many Windows virus checkers are a factor as well, especially those that
> check on every disk write.
>
> 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.
>
> For some file in a framework swc like UIBase.js, it should not be written
> to bin/js-debug/ on every compile.  The file is pulled from the SWC on a
> "clean compile" and remove-circulars writes some information about the
> dependency tree into that file.  On subsequent compiles, the
> remove-circulars code should notice that information and read it and not
> write UIBase.js again.
>
> It may be that some files must be rewritten to re-compute static
> initialization order, but that should be a small fraction of the total set
> of .js files.
>
> 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?
>
> I've never seen that.  Taking a quick peek at the code, I noticed that
> MXMLRoyalePublisher is checking configuration.release() which sounds right,
> but configuration.release() is actually checking an uninitialized boolean
> (and probably the wrong one (it is checking verbosestacktraces instead of
> generatedebugtags)).  I think in Java an uninitialized Boolean is false, so
> that should still work correctly.
>
> HTH,
> -Alex
>
> - Josh
>
> On Thu, Jun 27, 2019, 9:35 PM Alex Harui 
> 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" 
> 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%7Cb7d2d753f6bf45030c5808d6fbdcb704%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636973322722195130&sdata=k958a9JIVlYTmpyvbdvpYIutG3tgVvSsA4L0xlLyFuU%3D&reserved=0
> > >
> >
> >
> > On Wed, Jun 26, 2019 at 2:42 PM Josh Tynjala <
> joshtynj...@apache.org>
> > 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
>

Re: Compiler Performance (was Re: Problem with Vectors)

[Alex Harui]

On 6/28/19, 8:24 AM, "Josh Tynjala"  wrote:

Windows and PowerShell.

I've noticed my windows builds (command prompt, not powershell) are 
significantly slower than my Mac, but never investigated further.  Maybe my Mac 
has more or faster cores and memory.  But I've often wondered if the many 
Windows virus checkers are a factor as well, especially those that check on 
every disk write.

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.

For some file in a framework swc like UIBase.js, it should not be written to 
bin/js-debug/ on every compile.  The file is pulled from the SWC on a "clean 
compile" and remove-circulars writes some information about the dependency tree 
into that file.  On subsequent compiles, the remove-circulars code should 
notice that information and read it and not write UIBase.js again.

It may be that some files must be rewritten to re-compute static initialization 
order, but that should be a small fraction of the total set of .js files.

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?

I've never seen that.  Taking a quick peek at the code, I noticed that 
MXMLRoyalePublisher is checking configuration.release() which sounds right, but 
configuration.release() is actually checking an uninitialized boolean (and 
probably the wrong one (it is checking verbosestacktraces instead of 
generatedebugtags)).  I think in Java an uninitialized Boolean is false, so 
that should still work correctly.

HTH,
-Alex

- Josh

On Thu, Jun 27, 2019, 9:35 PM Alex Harui  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"  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%7Cb7d2d753f6bf45030c5808d6fbdcb704%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636973322722195130&sdata=k958a9JIVlYTmpyvbdvpYIutG3tgVvSsA4L0xlLyFuU%3D&reserved=0
> >
>
>
> On Wed, Jun 26, 2019 at 2:42 PM Josh Tynjala 
> 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). Yo

Re: Compiler Performance (was Re: Problem with Vectors)

[Harbs]

I’ve noticed this too.

> On Jun 28, 2019, at 6:24 PM, Josh Tynjala  wrote:
> 
> 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?

Re: Compiler Performance (was Re: Problem with Vectors)

[Josh Tynjala]

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  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"  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 
> 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  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

Re: Compiler Performance (was Re: Problem with Vectors)

[Harbs]

It looks like there’s still some noise which could probably be removed.

Compiling the framework SWCs produce output like this:

 [java] blockCount is: 15
 [java] block 0
 [java] [getlocal0, pushscope, newcatch(0), dup, setlocal(5), dup, 
pushscope, swap, setslot(1), getlex[Qname: 
e::{PackageInternalNs:"org.apache.royale.events"}], debugline(97), 
getproperty[Qname: name::{PackageNs:""}], pushstring[stopImmediatePropagation], 
equals, not, debugline(97), 
iffalse[org.apache.royale.abc.semantics.Label@16eedaa6 => 71]]
 [java] visiting block: 0
 [java] max_scope is now:2
 [java] scpDepth is now:2
 [java] block 1
 [java] [popscope, debugline(100)]
 [java] visiting block: 1
 [java] max_scope is now:2
 [java] scpDepth is now:1
 [java] block 2
 [java] [pushfalse, returnvalue]
 [java] visiting block: 2
 [java] max_scope is now:2
 [java] scpDepth is now:1
 [java] block 3
 [java] [getlex[Qname: e::{PackageInternalNs:"org.apache.royale.events"}], 
debugline(98), throw]
 [java] visiting block: 3
 [java] max_scope is now:2
 [java] scpDepth is now:2
 [java] block 4
 [java] [getlocal0, pushscope, 
debugfile[/org/apache/royale/0.9.6;org/apache/royale/events;EventDispatcher.as],
 debug[1,event1,0,0,]]
 [java] visiting block: 4
 [java] max_scope is now:3
 [java] scpDepth is now:3
 [java] block 5
 [java] [getlocal1, debugline(81), 
iffalse[org.apache.royale.abc.semantics.Label@33a3c44a => 38]]
 [java] visiting block: 5
 [java] max_scope is now:3
 [java] scpDepth is now:3
 [java] block 6
 [java] [pushfalse, setlocal3, getlocal3, returnvalue]
 [java] visiting block: 6
 [java] max_scope is now:3
 [java] scpDepth is now:3
 [java] block 7
 [java] [debugline(82), getlocal1, typeof, pushstring[string], equals, 
debugline(82), iffalse[org.apache.royale.abc.semantics.Label@6137cf6e => 28]]
 [java] visiting block: 7

> On Jun 27, 2019, at 12:42 AM, Josh Tynjala  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  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 bug

Re: Compiler Performance (was Re: Problem with Vectors)

[Alex Harui]

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"  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 



On Wed, Jun 26, 2019 at 2:42 PM Josh Tynjala  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  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 ot

Re: Compiler Performance (was Re: Problem with Vectors)

[Josh Tynjala]

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 


On Wed, Jun 26, 2019 at 2:42 PM Josh Tynjala  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  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

Re: Compiler Performance (was Re: Problem with Vectors)

[Josh Tynjala]

Wow! So for larger projects, it might have an impact beyond 20-25%. That's
great to hear. Thanks for sharing that stat, Kenny!

--
Josh Tynjala
Bowler Hat LLC 


On Thu, Jun 27, 2019 at 7:58 AM Kenny Lerma  wrote:

> I had some suspicions about the logs slowing things down.  I have 100s of
> very large projects and just tried the new build...amazing.
>
> I went from 80 seconds down to 20 in build time.  This is huge for me!
> Please keep going! :)
>
> Kenny
>
> On Wed, Jun 26, 2019 at 4:42 PM Josh Tynjala 
> 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  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 b

Re: Compiler Performance (was Re: Problem with Vectors)

[Carlos Rovira]

Congrats Josh!

yeah! prints use to slow down compilations so great fix! :))

El jue., 27 jun. 2019 a las 16:58, Kenny Lerma ()
escribió:

> I had some suspicions about the logs slowing things down.  I have 100s of
> very large projects and just tried the new build...amazing.
>
> I went from 80 seconds down to 20 in build time.  This is huge for me!
> Please keep going! :)
>
> Kenny
>
> On Wed, Jun 26, 2019 at 4:42 PM Josh Tynjala 
> 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  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

Re: Compiler Performance (was Re: Problem with Vectors)

[Kenny Lerma]

I had some suspicions about the logs slowing things down.  I have 100s of
very large projects and just tried the new build...amazing.

I went from 80 seconds down to 20 in build time.  This is huge for me!
Please keep going! :)

Kenny

On Wed, Jun 26, 2019 at 4:42 PM Josh Tynjala  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  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"  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  wrote:
> > > I had a long discussion with Alex last 

Re: Compiler Performance (was Re: Problem with Vectors)

[Harbs]

Awesome! :-)

> On Jun 27, 2019, at 12:42 AM, Josh Tynjala  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  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"  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  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 

Re: Compiler Performance (was Re: Problem with Vectors)

[Josh Tynjala]

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  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"  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  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 o

Re: Compiler Performance (was Re: Problem with Vectors)

[Alex Harui]

Folks are welcome to try various incremental compilation ideas.  I'm not sure 
you can guarantee a benefit in all cases when compiling from the command-line 
because you still may have to parse every file that is a dependency or 
encode/save/reload some sort of state cache.  There should be ways to get a 
benefit when compiling from an IDE because the IDE is your state cache and the 
compiler has some hooks for that.  But the old Flex MXMLC algorithm had bugs so 
I'm not sure I would borrow from that.

BTW, I ran across another jumble which is how much code is run in 
IdentifierNode.resolve.  I have often wondered why it must be so complex and 
whether passing context around would help.  Or prioritizing project scope class 
lookups over multiname lookups.

-Alex

On 6/17/19, 1:09 AM, "yishayw"  wrote:

Without knowing much about the compiler, what about incremental compilation?
Can gains be made by checking for source update timestamps and making a
decision as to whether or not to transpile based on that?



--
Sent from: 
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-development.20373.n8.nabble.com%2F&data=02%7C01%7Caharui%40adobe.com%7Cdb2b5c9e69a64cb8137a08d6f2fb2063%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636963557726154820&sdata=DorMV4v6H%2Bh4rcLM4Xp%2FydqX335SGqhwvN2UtGLvCaQ%3D&reserved=0

Re: Compiler Performance (was Re: Problem with Vectors)

[yishayw]

Without knowing much about the compiler, what about incremental compilation?
Can gains be made by checking for source update timestamps and making a
decision as to whether or not to transpile based on that?



--
Sent from: http://apache-royale-development.20373.n8.nabble.com/

Re: Compiler Performance (was Re: Problem with Vectors)

[Alex Harui]

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"  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"  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  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  
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 als

Compiler Performance (was Re: Problem with Vectors)

[Alex Harui]

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"  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  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  
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  wrote: 
> >> I'm not sure I understand the question.  I suspect it would be up