Well I agree that it would be good to share instances of things, but not configuration. Especially not sharing stuff between different instances of different compilers. Just as an example: MXMLJSC sets a different backend then COMPJSC does ... sharing breaks things here.
In Ant you do fork="yes" but forkMode="perBatch" so I guess you end up with one VM for the unit and one for the integration-tests. maven currently runs both in the VM of the build (default setting which is highly efficient). Talking about performance, I would opt to still make things maintainable and debuggable at the cost of a tiny bit of performance and pay the costs by fixing some other performance problems instead. For example by using some unsynchronized versions of containers instead of synchronized versions (Sonar is complaining greatly about this). And the cost of having a base set of interfaces that both implementations share and to have specialized interfaces that extend these to allow optimizations. How about that? So for example have an IElement which is used throughout the code and then there's a IJsElement which extends IElement and provides access to some JS specific stuff, that the rest of the application doesn't need to know about. Let's build a system that's safe and stable and optimize later on as we see ways to do that. I'm no big fan of pre-optimization ... you sort of never get it right. Chris ________________________________________ Von: Alex Harui <aha...@adobe.com> Gesendet: Sonntag, 8. Mai 2016 16:15:57 An: dev@flex.apache.org Betreff: Re: AW: AW: [FLEXJS] Probably found the reason for some of my problems ... On 5/8/16, 5:21 AM, "Christofer Dutz" <christofer.d...@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: https://cwiki.apache.org/confluence/display/FLEX/How+Falcon+Creates+SWFs 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. Thanks, -Alex
