I've found that compiling large embeds is *super* time consuming. The RSL solution seems best: this post from Darron Schall is relevant http://www.darronschall.com/weblog/archives/000168.cfm as are of course http://tinyurl.com/ynvqfe (livedocs for RSL) http://www.adobe.com/devnet/flex/articles/rsl.html You can make it so FB makes a buncha segmented RSL's for development, and have an ant build.xml which makes a static, optimized foot-to-ass final build that you publish and run regression tests on.
Large embeds necessarily imply a large runtime object. Do you need to @Embed all that stuff? If you can pull them in on demand without hurting the user (or programmer) experience you might be happier in the long term. On the Eclipse end, make sure your JVM is up to date, and look into bumping Eclipse's memory size http://wiki.eclipse.org/FAQ_How_do_I_increase_the_heap_size_available_to_Eclipse%3F (use the eclipse.ini options) and adding the memory status monitor and Runtime Spy: http://www.kyrsoft.com/opentools/memmon.html http://tinyurl.com/2fba8x (IBM: Runtime Spy) You can also consider turning off 'Build Workspace Automatically' in General/Workspace, and see if that helps. Finally, one pitfall: I had a project svn checked out from trunk, at the root, which included a subtree for the library and a subtree with several apps. The apps I had directly imported from the filesystem (since the lib project included all the subtrees). This meant that whenever one of the demo apps was compiled, it would trigger the lib to rebuild, which would cause the app to rebuild... ya. me dum. I fixed this to check out the lib and apps into separate projects and now the sun shines and birds chirp when I open FB. (BTW, if turning off 'Build Workspace Automatically' makes a big difference, something is doing bad touching somewhere in your workspace. See if you can find it, because it might be a recursive dependency like the one above). flip --- In [email protected], "desigaine pereanen" <[EMAIL PROTECTED]> wrote: > > Hi, one of the best solution to is is to go to the link > Project->Properties->Flex Applications and in the tree on > the right, only include the flex application you are currently > working on. Remove all the others from the tree. This would > cause flex to build only the applications that are found in this > tree. so if on another time you would like to work on another > one,just add it there before working because else the > changes you have made on the application will not be build during > compilation. hope this help you a lot in your development. > > On 8/28/07, Brian Holmes <[EMAIL PROTECTED]> wrote: > > Breaking the projects up and closing > > them does help a bit. Using ant helps sometimes. > > Using RSL's helps a bit. > > close all projects except for a sandbox project that I use > > to develop little bits of functionality quickly, cos that does > > build quickly, then go thru the long process of > > porting the code into my project. > > ------------------------------ > > > > *From:* [email protected] [mailto:[EMAIL PROTECTED] *On > > Behalf Of *Lachlan Cotter > > *Sent:* Tuesday, August 28, 2007 4:31 AM > > *To:* [email protected] > > *Subject:* [flexcoders] Flex Builder issues with large projects > > I'm having a lot of trouble with Flex Builder on a large project > > The particular project I'm working on is approaching 30,000 > > lines of code and also includes a fair bit of embedded assets > > in the form of skins and images etc. I am building several > > different products from the same class library. > > > > The first problem is that *compilation time is far too long*. Typically 30 > > seconds or more even after very minor changes to the source code, about 2 > > minutes for a clean build. It has become very difficult to do testing in > > particular as the delay for compilation break up workflow too much. > > > > I thought I would try to solve this problem by using RSL from Flex Library > > Projects as mentioned here: > > http://flexblog.faratasystems.com/?p=117 > > > > Any advice is greatly appreciated. > >
