As much as I like Flex, its five-hundred dollars tool has a LOT of room for improvements. I’m sure, Flash developers who did not see any better are happy with Flex Builder, but I came from Java World where excellent and free compilers and IDEs are the norm of life.
My main complain is that it’s extremely slow. Just to be fair, I need to acknowledge the fact that Flex compilers have to work much harder than their Java peers, because they need to perform additional duties like conversion of MXML to ActionScript, generation of the event listeners MXML components, binding support… But still, I want it to work faster.
How good is an incremental compilation if a recompile of a pretty simple application after changing the width of a label takes 20 seconds (I use 1.6Ghz laptop with 1.25Gb of RAM)? You call this incremental? Please…
I was hoping that adding -incremental=true as an additional compile option would help. No difference, and documentation helpfully explains that this option is already turned on by default in Flex Builder.
I’ve been using Eclipse with my Java programs for years and I did not know that I have to close projects that are not used at the moment. Now I know that if I won’t do this, Flex Builder will be even slower than it is now.
I never knew before that I may need to play with the heap size parameters and request more memory (xMs and xMx) for this memory addict.
mxmlc compiler is written in Java and comes as mxmlc.jar, which implies that you have to have Java Runtime Environment installed…and Adobe provides a four years old JRE of version 1.4. I guess they did not know that Java 5.0 was released more than two years ago. But it’s not that bad, you can install the fresher JRE on your own and reconfigure Flex Builder on your own to use it. But why ship a product in 2006 with an old JRE in the first place?
What about code refactoring that existed in Eclipse for years?
Oh, well you can’t get blood from a stone. If someone would ask me, “Name the most important improvement that Flex 2 needs badly”, I’d say, “Take care of Flex Builder. Now.”
Yours truly,
Yakov Fain
sascha/hdrs said,
November 18, 2006 @ 9:52 am
Can’t say that Flex Builder in particular works slow on my system (which is top-of-the-line though) but compile times could be indeed faster. Coming from MTASC, it’s quite a letdown to see it compile so slow. I also miss features like templates, mark occurance etc. but then there is FDT 2.0 (hopefully) coming soon.
Jason Fincanon said,
November 18, 2006 @ 10:47 am
Isn’t it funny that we (myself included) have gotten so spoiled with the constantly progressing speed of computers that we consider 20 seconds a long time to wait?
julien said,
November 18, 2006 @ 11:02 am
Hi,
I agree … FlexBuilder is extermly slow compared to using Eclipse for Java development … but even when i use VI, FlashDevelop or SciTE to edit my AS3/Flex code, when it comes to compiling gotta be a little patient
Guess that’ll be improved soon, they already improved lots of things since Flex 2 came out and that their’s no need to have the Flash IDE anymore
jon said,
November 18, 2006 @ 12:20 pm
“How good is an incremental compilation if a recompile of a pretty simple application after changing the width of a label takes 20 seconds…”
You’re probably embedded the entire font set. That’s what causes the 20 second delay–if it’s a common typeface, that could be over 3,000 characters. Even the largest projects I’ve worked on don’t take 20 seconds to compile… unless I’ve mistakenly embedded every character of the font set.
mike chambers said,
November 18, 2006 @ 12:26 pm
How large is your project? 20 seconds seems way too long, even for a very complex project.
I have a pretty large project that I work on daily, and incremental compiles take no more than a couple of seconds, and complete rebuilds take at most 5 seconds.
Can you post your example?
mike chambers
mesh@adobe.com
Yakov said,
November 18, 2006 @ 12:47 pm
Mike,
My project is fairly small. Actually, it’s two projects – one has three small MXML/AS files and it links to another project, which is a class library that contains about fifty small AS classes.
Can you please provide the description of the hardware you use for this large project (btw what do you call large?) and all config parameters of your Flex Builder that you’ve changed/tuned.
Thanks,
Yakov
Igor Costa said,
November 18, 2006 @ 1:15 pm
Yakov
It’s seems that you are not the only one, I use 1.8Ghz laptop AMD 64bits and 2GB of memory. And it tooks 50seconds to entire compile a project based on 5 components I did and 18 classes.
Uses of -incremental=true doesn’t really work properly, Instead of that, I just find it myself that Flex Builder had an JRE4′th old. I guess you found right now.
So, What I uses to take less time when I compile the project. Before you open your flex, in the Flex builder directory has an file called “FlexBuilder.confg” file, where has the ammount of memory that could be used to run the Flex Builder IDE.
By default I don’t remember right now what it was but also, if you want to try my configuration. go ahead. here’s the follow.
-vmargs
-Xms128M
-Xmx256M
-XX:MinHeapFreeRatio=10
Otherwise, I used before this one the switch between workspaces I guess it was pretty faster way before I discovered the solution above, As I also showed in the Flex-Coders maillisting the problem.
So, basicly I was stroumble introduced by this technique to watch out what’s wrong that’s is called Tuned up on IBM
http://www-128.ibm.com/developerworks/opensource/library/os-ecspy1/?ca=dgr-lnxw03RuntimeSpy&S_TACT=104AHW29&S_CMP=DVCHL
Regards
Yakov said,
November 18, 2006 @ 1:21 pm
There is one more tool that allows you to to monitor your Eclipse memory consumption – download the plugin from KyrSoft (http://www.kyrsoft.com/opentools/memmon.html) and just unzip it in your Eclipse installation directory. The excellent plugin not only allows you to monitor memory, but also request garbage collection when memory reaches specified thresholds (see Eclipse menu Window | Preferences | Java | Memory Monitor ).
This tool clearly shows that Flex Builder is hungry and eats lots of memory
Igor Costa said,
November 18, 2006 @ 1:28 pm
Yes I have this tool too.
And just show me how the Flex Builder eats a good memory. pretty badly.
Valery Silaev said,
November 18, 2006 @ 1:50 pm
Agreed regarding incremental compilation — seems that it doesn’t working at all, at least I see no time savings between compiling single file on save and executing clean build on whole project. However, I’ve noticed that this happens only for projects that contains mxml files. Projects with AS classes / binary assets only are built rather quickly.
Next thing is that Adobe probably should revisit packaging of a UI library inside single framework.swc file. I bet processing this highly compressed file during compilation eats fair amount of time. Overall, it would be better if Abobe used non-compressed version of swc files for compilation.
Also it seems that compiler itself is run as separate process for every invocation (rather then pre-loaded in-memory Java class). Java starts applications slowly. Even if client JVM 5 now may start UI applications quickly, it is still unacceptable slow for frequently used command-line tools. So I’d like to see next version of Flex compiler inside FB as pre-loaded plugin(?) that stays in memory and hence does not add own load time to overall compilation time.
VS
Ted Patrick said,
November 18, 2006 @ 5:18 pm
Yakov,
I use Library Project to speed up compile times by moving code into RSLs during development. With RSL’s the compiler simply excludes any assets in the RSL completely avoiding the compiler hit. Typically I find I am recompiling code that doesn’t need to be compiled again at all. Move it to a Library Project and load it at runtime during development to avoid the compilation hit entirely.
1. Make a Library Project
2. Add classes into the library.
3. Configure App Project properties to include the Library with RSL settings.
4. Done. Compile times should be back to normal.
Also something does sound funny with 20 sec compile times, I have yet to see this in FX2 at all. Are you using a special font type? Font encoding is slow as a dog, but you can add the fonts into a Library project too! Because fonts are embedded into SWF, target machines do not need to have the fonts installed. With all other platforms, fonts are imported from the target os, not with SWF(its optional).
The key with MXMLC is that it is much more than a compiler. Comparing it to MTASC or other compilers is not a fair comparison. MTASC just compiles AS to bytecode, it does not do MXML/AS translation, font and media encoding, image encoding, or component packaging. When you compare MTASC to ASC, ASC blows right by it. The longer compile times are directly due to asset inclusion, fonts imaging, images, component insertion, media encoding, etc. You can easily move these into a library project and recover 100% of the slowdown.
2007 is shaping up to be an amazing year for Flex. More to come!
Cheers!
Ted
Yakov said,
November 18, 2006 @ 6:03 pm
Ted,
I’m aware of RSL, but in this particular case I was making a change in the class that was sitting inside that swc
I remember, about ten years ago Microsoft’s software engineers working on their tools were given slow computers for testing on purpose. I wonder if Adobe can consider something like this? Can you share with us what type of computer are you using at work unless it’s a commercial secret…
It’s better to be healthy and rich than poor and ill:) It’s great to use dual core desktops with 3Ghz CPUs and 2Gb of memory, but people in the real world are using a lot slower machines provided by their employers.
All the best,
Yakov
Valery Silaev said,
November 18, 2006 @ 7:07 pm
By the way, what JDK version are you using.
Just found this Adobe support tip: http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=6b9902e9
My both versions of JDK 1.4/1.5 falls in slow category, have to check performance with latest releases…
Ted Patirck said,
November 18, 2006 @ 7:47 pm
Well I demo and test everything (FXB, FDS+Tomcat) on a IBM Thinkpad T41, 1.4GHz Pentium M 512MB running WINXP SP2. Many of the engineers use Thinkpads or Mactel laptops. Although I recently got a Mac pro and it is so fast that it idles at 1% cpu regardless of what I do.
What are the hardware specs you are compiling on?
Are you seeing long compiles using compc during SWC creation?
or mxmlc during app compilation?
Have you opened a support ticket?
I still think something else is going on here. Lets dig a bit a find out what is up.
Happy to help.
Ted
sascha/hdrs said,
November 18, 2006 @ 11:06 pm
Don’t use this MemTool from Kyrsoft! I managed to mess my Eclipse Panel Layout up and there was no way that I could repair it. I completely uninstalled the plugin but Eclipse still messed up. In the end I had to re-install Eclipse and my workspace.
Anatole Tartakovsky said,
November 19, 2006 @ 11:17 am
Ted, I think I understand complaint from Yakov and other guys somewhat differently. UI tool, unlike most of the back-end programming, has to have “instant” compilation time. While FB2 is great during first few month of the project, it becomes slower as the project progresses and more “stuff” ends in multiple places. As an example, the current code base on the project I am helping with is over 5MB. Refactoring helps a lot, but you need to modify RSLs as well – they are just application modules like everything else. The complete “clean” build time is about 3 minutes – 1 minutes for Flex part, 2 minutes for Java code generation and overall non-flex compilation/deployment. That is good and does the job on par with Java tools.
However, waiting even 30 seconds between the save and runs while you are writing/testing the code is too much for developers. There are places ( I believe I reported them to support) when typing a single character can cause FB2 to hang for 20+ seconds in the middle of editing (3+GHZ, 2+GB RAM). While the later is just a bug that will be obviously fixed as more MXML applications will appear, the overall build time is a great concern as it affects developers concentration. Just assume it happens to you – hit run button and do not go in for 20 seconds – you development pattern will change drastically.
What helped older environments in the same category (talking PB again) was truly incremental compiler/linker. The package catalog was much more elaborate then SWC one and included all methiod/props/metadata along with dependencies – was updated by compiler at the time of file save of each individual file. It does not not need to be part of the final SWC or SDK but might be used by incremental compiler in the FB environment. As a result, RSLs for the app were always ready and deployed for instant use in loosely coupled architecture – with option of complete rebuild at developers discretion.
Sincerely,
Anatole Tartakovsky
Jason said,
November 20, 2006 @ 2:14 am
I had seen this same problem, but after installing the GMC0 for FB2 2.0.1 release and the compile time has droppe to about 4-5 seconds instead of the 30+ seconds before. So it appears they have made some optimazations here. I can actually now turn on build automatically and it “works”, there is still a little hiccup but nothing that will slow my work down.
Yakov said,
November 20, 2006 @ 11:15 am
I work with FB 2.0 and use JRE 1.5.09. I’ve set up my JAVA_HOME dir and removed the original JRE folder from Flex Builder install.
I have two projects in my workspace – a small Flex project and a Library project listed in the build path of the main project. If I have both projects open, any little change in the source code of the library project like adding a space chatracter causes at least 15 sec of rebuilding the workspace. If I leave only Library project opened, the same code change rebuilds the workspace in sub second.
Unfortunately, I can’t test my application when the main project closed
Ted Patrick said,
November 20, 2006 @ 2:51 pm
I am thinking this is almost certainly a bug. So lets address it.
Anatole, Yakov can you send me a build and configuration so I can duplicate the build environment and present this to engineering. There are development cases that occur that are impossible to understand without seeing the compilation times first-hand. If we can see the problem, we can fix it. If we cannot see things fail, we are guessing at the problem. Considering your team is writing some of the most sophisticated Flex 2 projects I have seen, you are testing Flex under extreme conditions that we need to understand first-hand.
Personally I would like to see a public Flex bug base running in Atlassian JIRA that everyone can contribute to. This will take some time to get operational but I think it will dramatically raise the quality of the Flex and allow our amazing community to participate directly.
My hunch is that this is better in 2.0.1 but I want to make 3X sure of it.
Thanks for posting this Yakov. Again, happy to help. Ted
Josh Tynjala said,
November 20, 2006 @ 7:50 pm
While I don’t have any performance issues on my machine at work (about a year old), my machine at home (about three years old… 2.4GHz, 768MB of RAM) runs Flex Builder pretty darn slowly. I have to turn off the automatic compilation or I’ll get 10-15 seconds of HEAVY cpu usage every time I save a file after editing. I’d definitely like to get my hands on 2.0.1 to see if there’s any difference, Ted
Yakov said,
November 21, 2006 @ 1:29 pm
BTW, I forgot to mention that I’m using FlexBuilder plugin under Eclipse 3.2 – I wonder if there are any issues specific to 3.2?
Rauf Qureshi said,
November 21, 2006 @ 3:31 pm
I am glad that I stumbled upon this blog! I have been debating myself whether to give Flex a try or not. I guess I will wait until the development environment becomes more rewarding.
Rauf
Anatole Tartakovsky said,
November 21, 2006 @ 3:37 pm
Rauf,
You should definetly try the environment – it is definetly a RAD and we are being really impatient bunch. Overall development process is order of magnitude faster then regular JEE. It will be quite a few man*years till you get a chance to complain about this issue – and with the bug fixing maintenance releases and tools popping up the chances it would affect newcomers are slim.
Sincerely,
Anatole Tartakovsky
Rostislav Siryk said,
February 16, 2007 @ 3:01 pm
As I have learned, Flex Builder 2 behavior hardly relies on computer hardware. During the last week I used to develop Flex project at the machine with very outdated hardware configuration, nearly 6-7 years old:
– Processor: Celeron 700
– RAM: 327 MB
– Video: Rive TNT 2
I’m excited how tiny the Flex Builder performance decrease was at this old machine. Yes, it works slower, but just A BIT slower than my just upgraded office machine I use everyday for Flex development.
However, FB2 hiccups still here, there and anywhere: as I learned, FB2 freezes mostly on Refreshing workspace operations and builds.
So I think there’s not so much sense in comping your CPUs and other hardware specs. I think the root of the FB2 hiccups problem is unoptimized complex dependency analyzer in FB2.
So if it freezes, it freezes anywhere.
anatole tartakovsky said,
February 17, 2007 @ 11:19 am
Rostislav,
Add images, libraries and work on the project beyond 4 weeks. Keep incremental compilation on. As your project progresses, your changes become smaller and compiler response time longer. Toward the end of the project it reaches critical importance.
In old (circa 80s) environments p-code (or bytecode as they call it these days) was kept in source-control enabled repositories along with the source, so the proocess of build was very much linkage only. You had to run regen (clean rebuild) from time to time, but you would be OK 99.99% of the time with instant runs. It was extremely important for large projects.
I guess it will take a while for this technologies to come back
Regards,
Anatole