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.
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. Chris [1] https://en.wikipedia.org/wiki/Thread-local_storage#Java [2] http://stackoverflow.com/questions/1202444/how-is-javas-threadlocal-implemented-under-the-hood ________________________________________ Von: Alex Harui <aha...@adobe.com> Gesendet: Sonntag, 8. Mai 2016 07:23:43 An: dev@flex.apache.org Betreff: Re: AW: [FLEXJS] Probably found the reason for some of my problems ... On 5/7/16, 12:01 PM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote: > >I agree that the initial version doesn't have to be perfect. But we have >to keep track of such places and make sure to clean them up as soon as we >have some time. Perhaps it would be a good idea if implementing something >we know is hacky, to create an Issue for cleaning up? > >It's just that tracking down stuff like this comes close to being >impossible. I was confused why the backend I put in when creating the >COMPJSC instance wasn't there when using it. I could only track that down >by using an insanely expensive property-access-breakpoint. Just curious, what is the advantage of creating instances of every tool in the group? I'm not clear it was intended for sharing between instances of the compiler, just for sharing data from various places in the compiler. I'm not a Java VM expert, but I think when we do builds we create an instance of the compiler, compile something, destroy that instance, create another instance, compile that next thing, etc. Which is pretty much what would happen on the command-line. Are you trying to keep certain things in memory so the start up doesn't have to happen every time, sort of like fcsh? Thanks, -Alex
