I'm working on a Flex project that has 28 modules, and 1 main SWF. Compiling everything takes 18 minutes total. I'm using load-externs to load a link-report from my main SWF - that works great. The file size of the modules is minimal. But link-checking still occurs for each individual module, increasing the compile time dramatically.
So say I edit a file in my main SWF that a module uses. mxmlc basically performs link-checking for the same file in that module. Even when -incremental=true. When I edit a file that ALL of the modules reference (which happens frequently), ALL of the modules perform link-checking. This has the effect of basically compiling the main SWF 28 times.
This is frustrating, because link checking occurs when I compile my first SWF. It should not have to reoccur for every module. I tried using fcsh, which would hopefully store these links in memory, but that had no effect.
Maybe it would help to compile a SWC of my main SWF, and use that for link-checking instead?
Here are the commands I use to build:
mxmlc -link-report=report.xml -strict=true -debug=false -optimize=true -incremental=true Project.mxml
mxmlc -load-externs=report.xml -strict=true -debug=false -optimize=true -incremental=true ModuleXX.mxml # 28 times
I haven't found a solution for this problem and it's hindering the development of my project. Any help would be greatly appreciated.
Thank you!
Jimmie
I agree that 18 minutes is a very long build time, but this kind of module size optimization should only be necessary on a release build. So my simple recommendations are
Don't use compiler optimization during development time
Only recompile the modules you are working on
Upgrade your hardware
Upgrade your software (the Flex 4 compiler should be faster than Flex 3)
we have this problem but can't find a solution. We have an application that references something like 24 dlls. When you invoke the application the very first time (after the application is for any reason reset) it takes 25-40 seconds to start loading contents.
This is what we tried:
1. precompile and publish everything in release mode
2. removing pdbs from bin folder
3. put strong named assemblies into GAC
4. set application to debug = false
Please consider that the whole bin folder is composed by 24 dlls for a total size of 28MB. Just 4 of these dlls are strong named and they are more and less 25MB.
Nothing seems changed. What happens EXACTLY when the application is started is something I couldn't find in any book nor forum/blog/post... What can we monitor more to find where the problem is?
Thanks a lot for your help,
Marco
Looks like you will need to use NGen...
The Native Image Generator (Ngen.exe)
is a tool that improves the
performance of managed applications.
Ngen.exe creates native images, which
are files containing compiled
processor-specific machine code, and
installs them into the native image
cache on the local computer. The
runtime can use native images from the
cache instead using the just-in-time
(JIT) compiler to compile the original
assembly.
Precompile the website for deployment, using fixed names, deploy the solution to the server, and then ngen all assemblies in bin
MSDN article on NGen.
Our application has over 15 different top-level mxml files to create individual controls that are used in our pages.
We are using Ant to do our automated builds, and are calling the mxmlc task for each mxml file separately (See question 78230 similar example). Running the compiler separately for each mxml file, however, is already adding up to a considerable amount of time. Our build time is approaching 10 minutes, 5 minutes for compiling our flex apps, and 5 minutes for compiling hundreads of java classes, building jars, installer etc. Each flex compile run is reasonably quick (15-20 seconds), but they add up.
Is there a way to compile all of them with one call to mxmlc?
One way to speed it up a bit is to compile everything but the top-level classes into one big SWC using compc, then compiling the top-level classes and using the SWC as a library. That way classes that are used by more than one application will only be compiled once.
However, a large contributor to the time it takes to compile a Flex application is the JVM startup time, and each compile will start up it's own JVM (plus one for the Ant process). One way to avoid this is to use the Flex Compiler Shell (fcsh) instead of Ant, but that has it's downsides of course. Another way is to try HellFire, which runs the compiler in a separate always-on process, meaning no more waiting for the JVM to start.
Why not use Flex Builder to compile everything automatically?
Are the mxml files components and/or modules? I think that mxmlc compiles them automatically it they're linked to by the main application, but I'm not sure...
I am making a very large web app (currently at 70 projects and 150k loc but with a lot more to do).
I use FinalBuilder to run build scripts. However, what are the best practises for structuring such a large project? What about build dependencies? What effect does the structure of my projects have on the performance on the code (if any)?
I've seen some previous threads about this but I can't find those. I've seen threads about solutions exceeding 600 projects in the solution, for the sake of clear answers, lets imagine this system will grow to that size (I would like to know how to organise a project bigger than what mine ends up to be, as it would mean I can organise a smaller solution).
If it matters, the system is mostly in .NET 3.5 (C#, LINQ, SQL Server etc) but will use Python/Erlang too.
I have only 40 projects (but several millions of loc), and the main best practices we have is:
identify dependencies between projects
establish a global list of labels used by all projects wishing to participate to the next release
make sure that every project willing to publish a label of its own into this global list has made that label from a configuration (list of labels) coming from the global one
register the "officials builds" (the one potentially to be deployed into production) into a repository.
That way:
developers works and compile their code directly against the deliveries of the other projects they depends on (as opposed to download the sources of the other projects and rebuild all in local).
They only have the right deliveries because they know about their dependencies (both immediate and transitive)
testers can deploy quickly a set of deliveries (from the global list of labels) to perform various tests (non-regression, stress-tests, ...)
release management can deploy those deliveries (after having a final global build) onto pre-production and production platforms
The idea is to:
not rebuild the delivery at every steps
build it only at the development stage (through a common unified building script)
build it again before release (for pre-production and production platform)
compile and/or test only against those deliveries (and not against sources downloaded and re-compiled for the occasion: when you have more than a few projects, it is just not practical)
Main best-practice:
If your own project works with the deliveries of the other projects (and not with your local re-build of those other projects), it have good chances to work in the next steps of the software production life-cycle (test, pre-prod, production)
Have you considered using NMaven and making each of the 70 projects a module? That would allow you to control the building, packaging, versioning, and release of individual modules and the parent project as a whole. It would also help you resolve the depedencies between the different modules, external libraries, and even versions and different lifecycle scopes (for example, you only need NUnit during the testing lifecycle, but don't need to package it in the build).
It might help to explain in greater detail what these projects look like and how they depend on each other.
A bit open as a question. Let's start with a basic structure I suggest as a starting point to my customers, inside a branch I have
Build Scripts
Build Dependencies - things to install on a build machine
Libraries - LIB, DLL, ... directly referenced from projects
Documentation Sources - help sources
Sources
Deploy Scripts
then Sources is organized in
Admin - admin console and scripts
Database - schemas, scripts, initial data
Common
Web
NTServices
Services - REST/SOAP services
BizTalk - you name things specific to a product
I run Flex Builder 3 on a mac and as my project grows - the compile time gets longer and longer and longer. I am using some SWC's and there is a fair amount of code but it shouldn't take minutes to build and crash daily should it?
First of all, comments on some of the response:
There is no need to explicitly specify -incremental in Flex Builder because it uses incremental compilation by default.
-keep-generated-actionscript is a performance killer because it instructs the compiler to write out AS3 codes generated for MXML components in the middle of the compilation. File I/O in the middle of a compilation means unnecessary pauses and low CPU utilizations.
-optimize slows down linking because it instructs the linker to produce smaller SWFs. Note that -optimize=true|false doesn't have any effect on building SWCs because SWCs are libraries and have to be unoptimized.
I rarely mess with JVM settings because JVM knows its jobs well and tunes itself quite well at runtime. Most people make matter worse by setting various GC tuning parameters. That said, there are 3 settings most people understand and set correctly for their usage:
-Xmx (max heap size)
-server or -client (HotSpot Server or Client VM)
-XX:+UseSerialGC or -XX:+UseParallelGC (or other non-serial GC)
-server consistently outperforms -client by about 30% when running the Flex compiler.
-XX:+UseParallelGC turns on the parallel garbage collector. ideal for multicore computer and when the computer still has CPU cycles to spare.
You may also want to check out HellFire Compiler Daemon (http://bytecode-workshop.com/). It uses multiple processor cores to compile multiple Flex applications at the same time. You can also run the compiler on a second machine via sockets (assuming that your second machine has faster CPUs and more memory).
In my opinion, use more modules than libraries and use HFCD.
Hope this helps.
-Clement
There's no need to use mxmlc on the command line just to be able to add compiler flags. Right click your project in the Flex Navigator, select Properties and then Flex Compiler in the dialog that appears. There you can add any extra compiler flags.
Not sure that there's very much to do though, more code means more compile time, that's just the way it is. If you're not doing a release build (or whatever it's called in Flex Builder) it's unlikely that your compiler settings include optimize to begin with. Better choices to try would be -incremental (which only recompiles the parts that have changed) and -keep-generated-actionscript (which stops the compiler from deleting the ActionScript files it has generated from your application's MXML files).
I very much prefer using mxmlc on the command line (by way of Ant) compared to Flex Builder. Although I don't think that the latter compiles any slower, it feels more sluggish in every way. Using Ant also makes it possible to do more than just compilation when building, and conditional compilation (only compile a SWF or SWC if the source code has actually changed). Check out a blog post of mine for more info on that.
What you could try is the Flex Compiler Shell, another command line tool that can speed things up. Basically it tries to keep as much as possible in memory between builds, so no need to wait for things like the JVM starting up (the Flex compiler is a Java application). On the other hand this is sort of what Flex Builder does anyway.
In addition to the suggestions already mentioned, close any projects that you have open that you are not using.
Rich click on the Project in the Navigator view and select "Close Unrelated Projects".
Depending on how many projects you have open, this can lead to a significant improvements in compile time, as well as all around performance.
mike chambers
mesh#adobe.com
Slow compile time is most often caused by having large numbers of embedded resources ([Embed] or #Embed).
Option 2 on this article might help you: [http://www.rogue-development.com/blog2/2007/11/slow-flex-builder-compile-and-refresh-solution-modules/]
I created RAM Disk with workspace and it gives up to 10% of better compilation time. Not much, but something.
You want at least 4 gigs on your computer if possible, and make sure to override the default memory settings that eclipse/flexbuilder gives to the application.
If you're not sure how to do this, you can find the flexbuilder app in /Applications, right click and choose "Show Package Contents". Then go into the contents file and edit the eclipse.ini file. Edit that file have memory settings of at least:
-vmargs -Xms768m -Xmx768m -XX:PermSize=128m -XX:MaxPermSize=128m
It's also worthwhile to go into the eclipse/flexbuilder preferences and to check the "Show heap status" box under Windows->Preferences->General (This is in eclipse with the FB plugin, I'm assuming it's also there for standalone FB).
This shows the current memory in the lower right of the window and has a little trash icon so you can force garbage collection.
I'd also suggest turning off automatic building of the project when your files change (you can force a build with cmd-B).
We had a huge project with quite a few modules files and performance in FlexBuilder 3 was decent with these steps.
Go to Project->Properties->Flex Applications. All of the applications listed are compiled each time (even though you have a default set). If you remove everything but the default (don't worry, it won't delete the actual files), it only compiles the default app. This resulted in a significant speed up for me. If you change your default app, it ADDs it to the Flex Applications list - adding to your compile time. You will need to maintain this list to get the quickest compile.
I always disable "automatic compile" for Flex. It compiles too much, takes too long, and so interrupts my work.
If you have many different project files and all of those needs to be recompiled, but you also have other projects open and don't want to close them always you're doing a build, you can also use Eclipse Working Sets.
Unfortunately, the default Flex Navigator does not support working sets. But you can open the Package Explorer with Window / Show View / .... Click on the little white downward arrow to the topright and select Top Level Elements: Working Sets. You can then add Working Sets (aka groups of projects). Each project needs to be in at least one working set ("Other Projects" being the default), but can be in several.
Now with Project / Build Working Set / ... you can instruct Eclipse to build all the projects in this working set, but none of the others. This is especially useful if you suspect your project references to be sometimes broken - otherwise building the 'topmost' project should trigger subsequent builds automatically.
As Clement said, use the HellFire Compiler Daemon. If you have multiple modules and more CPU cores on your machine it can compile them in parallel. Another option is to use IntelliJ (the commercial version) which offers the same feature.
The SDK 4.x.x introduced silly bug (see Adobe bugsystem, issue FB-27440), which causes projects with SVN or CVS meta data compile much slower than with SDK 3.x.x. On how it can be fixed, see here.
You may want to explore the command-line compiler found in the Flex SDK, mxmlc. As I recall, Flex Builder 3 seems to hide all the compiler details, but perhaps there are arguments you can append that will help you speed up the compilation.
For example, you may want to set optimize=false which will skip the step of optimizing the bytecode (perhaps reducing compilation time)? This of course comes at the price of performance and file size of the actual application.
More documentation on mxmlc can be found at: http://livedocs.adobe.com/flex/3/html/compilers_13.html.
Good luck!
I don't use Flex Builder, but I use the Flex SDK compiler everyday and I was wasting tons of time waiting for the MXMLC compiler to do its job until I found Flex Compiler SHell:
http://blog.zarate.tv/2008/12/07/theres-something-called-flex-compiler-shell/
Although in theory Flex Builder already uses this optimizations, might be worth checking.
You can use WORKING SETS to compile just a set of your components that are part of the application that you are changing and not the whole project
http://livedocs.adobe.com/flex/3/html/help.html?content=build_6.html
Usually the first build takes the longest, and then it's pretty quick after that. That's using Vista x64 w/ core 2 duo.
Otherwise, I am nearly certain a Intel Core i7 Extreme Edition 965 3.2GHz upgrade processor would speed your Flex building up nicely .. :) :) :)