flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: AW: AW: [FLEXJS] Probably found the reason for some of my problems ...
Date Sun, 08 May 2016 14:15:57 GMT

On 5/8/16, 5:21 AM, "Christofer Dutz" <christofer.dutz@c-ware.de> wrote:

>Hi Alex,
>well actually the Ant build doesn't destroy the compiler, but the entire
>VM. To me it seems that for every compilation and every Unit test a new
>VM is forked. This is extremely expensive and time consuming. If you have
>a look at the Flex Jenkins and compare the build time of Falcon with Ant
>and with Maven, you will see that the Maven build runs in half the time
>while still executing all Unit and Integration tests except the hand full
>that need externs or the flex-sdk to run. Most of this speedup is due to
>the fact that I don't fork a new VM for everything.

Interesting.  I occasionally run into a problem on my system where the
Unit Tests run from Ant get real slow.  In searching the internet, it
appeared that a new VM was being created for each Unit Test even though I
think the settings tell Junit not to do that, and I think after a restart
my system suddenly runs the Ant tests much faster.  So maybe somehow Ant +
Junit + low memory doesn't allow a VM to be shared.

>Actually needing to fork is a measure of last resort. I know you might
>need to pass things through the compiler and access that state from
>different parts without wanting to pass along everything with each method
>invocation. Usually you use Threadlocals for this. I haven't come across
>this design pattern in Flex-related code. Perhaps it's worth having a
>look at it [1]. It's a variable that each thread has it's own value. So
>as soon as the same thread accesses the variable, it will get the same
>result, but another thread has it's own value. As Threadlocals were
>introduced with Java 7 you can still use what was used earlier ... A
>singleton that manages  a Map of Thread-Object pairs does the same thing
>and you no longer need to worry about leaking states between instances
>[2]. Then you could also utilize Maven concurrent builds and Surefires
>multiple test execution in which you can build multiple Maven modules or
>just Unit/Integration-tests in parallel, which dramatically speeds up
>build time, if CPU utilization is the limiting factor.

Before we go and remove all public statics, please take a moment to think
about the Workspace class and read about it on this page:
and the page it links to.  I didn't work on this code, but it appears
there is intention here to share stuff between instances of the compilers.
 I still think we need things to be efficient when the compilers are used
outside of Maven like in some IDE so I think we want to make sure there is
some way to share things.


View raw message