How do I streamline FlashBuilder for speed

[GoodNewsJim1]

I have massive lag between pressing keys and Flashbuilder responding.

I know about clicking off "Mark occurances" to gain a significant amount of speed.

I know about loading files as .text instead of .actionscript to gain speed

What is everything else I can do to gain speed?

[GoodNewsJim1]

This is important for me.

Flashbuilder constantly freezes and gives me 1-10 second type lag between pressing buttons.  I just had to ctrl+alt+delete because Flashbuilder went into not responding.

Is it because I have a massive project with more than 100,000 lines of code?  Is Flashbuilder simply not built to handle big projects?

I wish someone would give me tips on how to lower the processing Flashbuilder does to a minimum so I can debug my code.

When my project was small, debugging and typing was crisp.  Now it is like I'm in sludge.  You can recreate this system.  Type in a couple lines of nonsense code, then copy/paste recursively until you have 100,000 -300,000 lines of code.

[Starglider]

Flex, FlashBuilder is built on Eclipse.

The interpreter parses the text for syntax highlighter, error and warning messages.

The speed changes the larger projects get, but this is the same for all projects. Some can handle huge single files better than others. Some can handle 100,000s of files of reasonable size better than others etc.

You can try FDT but this is also based on eclipse.

You can also try FlashDevelop which is free.

Not sure if this will work but you could try downloading the latest and greatest version of eclipse and installing the flashbuilder plugins for it (google that info).

Recommendations:

1. If your file/class is over 1,500 lines of code then it's getting too big. Too many tasks for 1 class, try splitting it up work out sub classes and components.

2. Don't have a 100 files open at a time.

3. If the compile time is slow, nothing you can do about that apart from work from a SSD and get a 4 cpu motherboard with intel zeons in each with 64 cores cooled with liquid nitrogen. (You should try compiling for mobile or tablet devices - now that's a wait!)

4. Install the latest version of java for you OS (clutching at straws here)

D

[maretron]

This is important for me as well. I keep hitting the heap limit (-Xmx3854m in .ini file), so now I restart Flash Builder and run a Clean for very build.  Now I'm trying splitting the project up. Is there any guidance on how to split the project to maximize effiency?

[Starglider]

You can use frameworks but I find a lot of time is spent fighting with these frameworks to follow their rules so I came up with my own back in 2004.

It's an MVC but based on strong folderisation and relaxed MVC rules.

Folder structure

project_folder

| - bin-debug

| - bin-release

| - embedded_assets

| - swcs (for all your swc files)

| - libs (for all your code based libraries - tweenlite, away3d etc)

| - src

    | - assets (preloaded or loaded on demand)

    | - com

        | - project_name

            | - controllers

            | - models

            | - views

            | - utils (project specific)

        | - project_root_controller.as

            (Instantiated from default controller created on FlashBuilder project creation eg addChild(new project_root_controoler()))

project_root_controller.as

Main ini of your app and insantiator of all things

controllers

You can have many controllers to manage a single part of your app or just 1. If you have many make a sub folder called what it is managing eg game_controller or content_controller. Each of these folders would then have controller as files for loading, preloading, content switching and content clean up etc

models

XML Model for storing all your XML data or a class to retrieve your xml data on demand.

Constants class for singleton based variables (public static var ui_color:Number = 0xFFCC00; //etc)

etc

Views

A class which is a visible element of your application, which only has functionality to handle it's own behaviour (if part of a larger more complicated process then a controller should be created to call the view into existance and then managed by that controller - think of a controller as a manager if you like - 1 controller to manage many views and access as many models as it needs to make the combination of views work together in the desired manner)

utils

A collection utilities which are specific to helping to the creation of the project. If the utility has a more global scope it should be in the libs folder. eg over the years my libs folder has a huge collection of utility classes "com.darcey" which you can also download and use at http://code.google.com/p/darceys-as3-components/

libs

Collection libraries such as away3d, tweenlite etc

swc

I always create an empty fla (assets.fla) and generate an assets.swc file for every project. Just quicker to double click on the fla and add or create an asset for the project as and when needed that way.

So... Very minimal framework fighting.

Do as you want within the folders but the general guide is above.

No worrying about what should instantiate what as long as you just remember the controller is the manager which brings everything into existance.

If your controller manages a lot of views extend sprite so you can addChild it in the root controller.

If your controller manages events or data or responses of any kind just extend EventDispatcher.

So far projects with 100s of classes and 10,000s of lines of code have caused no slow down or compiler issues, and it's been a few years.

Good luck

D

[maretron]

Darcey - that was a quick reply, with a lot of great advice. I'll be going through it in detail. What I'm looking at though is miminizing the number of modules that are in memory at one time by creating multiple projects. I have no idea how Flash Builder combines modules from different projects, so this might just be a huge waste of time. Right now my project is over 75,000 code lines in 61 AS3 files, 30,000 code lines in 90 mxml files, plus another 56 swc files from Flash Professional.  This just seems to be too much for Flash Builder to handle.

I'm not finding any guidelines on how to break up large Flash Builder projects into smaller units.

[Starglider]

Ye, quick response as I'm waiting for ADobe to respond to my question, but I doubt they will......

You can load and unload as many swf's as you wish, just treat them as seprate applications.

One of the largest I have cooked up with my framework is:

1 x core application with nothing but the framework and preloading and loading handling. (various xml files and about 5mb of assets)

1 x home menu and core ui app (various xml files and about 10mb of assets)

9 x sub applications with about 1gb of video files, 5mb of xml and various images and sound assets in each

I had no problems with this at all...

[Starglider]

You need to think a strcture outside of the structure I detailed above for projects like that.

EG

ROOT APP

| - Home / Intro / Core / UI APP

      | - Module 1

     | - Module 2

     | - Module 3

     | - Module 4

     | - Module 5

     | - Module 6

     | - etc

Each app uses the strcutre I showed above, you can nest them in sub folders in 1 project in flashbuilder but if you ever have an issue with flashbuilder screwing up the project settings (which it does often) then you might be in for a bit of trial and error trying to set it up again. So what I do now is keep them seperate to their own projects but set the compiler to not use bin-debug and dump out to a folder manually created in the workspace folders called "www/assets/swf"

[Starglider]

++

Also the ebenfit of this is shared functions and data.

It can get messy a bit with this especially when loading swf's in, your root app will be the app domain.

So if you have content mangement and asset management in the root app and you load all your sub modules into the same domain you will have access to the root apps functionality which will change the way you build the sub applications but you can ignore this alltogether and just do it as normal.

Check safeloader and loading into same domain for maxloader and use a contsants model for setting a variable for easy access to your root app where you can call the functions of anything that is available to your projects root controller.

AppVars

public static var rootApp:RootApp;

Then in RootAppController.as you set it AppVars.rootApp = this;

[Starglider]

Just to cover your lasat points

1. I try to avoid Flex MXML applications as much as possbile, too much overhead, far too slow and memory intensive.

2. When loading modules / swfs in the strcutre I showed above you would write a content controller application which would dispose of your module when it is replaced by another module. Every class I reate (well 99% of them) have a public dispose function in them (especially the views) which allow me to call dispose in the root controller class of that module and it will free as much memory and clear all event handlers freeing up memory for garbageg collection. So you should only ever have 1. Root App, 2 UI Core app and 3 x 1 module in memory at 1 time.   You could even merge the root app and core ui app into 1.

[maretron]

I'm starting to think that mxml modules are my problem as well.    I guess I need to start laying things out myself

[Starglider]

When coding more efficiently you achieve the other automatically

Just a little bit of structure and keeping it simple

As for MXML applications, it was a nice idea by adobe but I've lost count the number of clients I've told to avoid MXML applications for mobile and tablet. And with the quality of AIR development tools (FlashBuilder) and the resulting products on iOS and Android at the moment I wont be suprised if Adobe loose the AIR war to a WebGL compiler which can compile to iOS and Android OpenGL ES and having JavaScript as the language of choice (I much pref' AS3 over JS), tools for vector graphic importation and animation will soon pop up and cost 1/10th the price of crash, cough Flash.

[maretron]

Thanks - simple is long gone unfortunately.  6 year old project, growing all the time, locked in.  uggh. 

I kept mxml out of the mobile versions, but we have too many set up dialogs in mxml on the PC version.  I'm now moving from mx: to spark: components to avoid a memory leak in mx:DataGrid, and it just seems to get worse.

Thanks for the chat.   All the best with your projects.

[maretron]

Reading back on this thread, I don't think I've been very clear.  I'm trying to help the compiler (Flash Builder) compile my code, not make my code run efficiently.  I think I have that under control.

[maretron]

Thanks again - and I hope Adobe responds to you.

My app seems to work fine, even at this size, and even runs okay (a bit slow) on an ATOM with Linux. (yeah - I'm stuck on AIR 2.6 because of that).    I'm trying to minimize the modules that the *compiler* has to keep in memory at one time.

Thanks for all the advice.  It's nice to know that people such as yourself are still developing *large* applications in Flex.