As the reason for most of these posts to come out, there’s been something that I’ve been fighting with for a very long time now. Flash Builder performance. It’s always been sluggish and quite frankly it’s a huge memory hog. Eventually I came across posts about how to increase the heap size of the java virtual machine that Flash Builder uses via adding -Xms and -Xmx switches with the appropriate values afterwards. But after a while Flash Builder will crash out with java heap errors, which directs me, yet once again, to go back and adjust those flags in the FlashBuilder.ini file. So how can I get this program to behave better? The trick brought back memories of the days when 64 bit processors where first introduced.
So what are -Xms and -Xmx? Some of you might be interested to know. The -Xms is the starting heap size and the -Xmx is the ultimate maximum that can be allocated for the heap. It’s suggested to set these two the same to prevent the Flash Builder from having to always re-allocate more memory through your daily usage. If you know you’re gonna hit or get close to maximum, them just make them the same and it’d save you some wait time in the IDE. Also keep in mind if you don’t need the large heap sizes, keep them within the right ranges. Your garbage collector will thank you as it’s faster to go through smaller memory spaces. Here are the settings I put in the FlashBuilder.ini file:
-Xms1024m -Xmx1024m -XX:MaxPermSize=256m -XX:PermSize=64m -XX:+UseParallelGC
I found that on my 64 bit machine I could only bring Flash Builder 4.6 up to a max of 1G. After that the java virtual machine would not start up and Flash Builder 4.6 would just hang at the slash screen. Even running at this max started to have it’s drawbacks. Every so often I’d get the java heap errors.
After a while I got savvy about how I use my IDE. I kept the number of open tabs down to a minimum. I didn’t keep search windows open for long periods of time and made sure to close them in both Flash and Flash Debug views. And finally, I’d monitor my heap memory usage and occasionally fire off the garbage collector, by enabling the “Show heap status” option in the Window -> Preferences -> General section. This kept heap errors at bay, but it was certainly a lot more “managing” than I felt necessary for an IDE.
Some time passed, and today I decided to tackle this once again. I started to look into how operating systems limit how much a single process is allowed to allocate. Then the good old chestnut of 32 bit versus 64 bit came back into my mind. Found that various people were hitting this imaginary wall at ranging values. I too, in the same day, was able to get the max up to 1280M, then 1152M and finally I got stuck back at 1024M. So clearly I’m hitting a limit because Flash Builder 4.6 compiled for a 32 bit architecture. Flash Builder 4.7 is build for 64 bit architectures, but it’s still in beta and missing Design view entirely, which is a huge timesaver for complex UI layouts.
So how do I get my heap beyond the limit? Through my searches I came across this:
Yes, that’s a Russian site, so thank goodness for microsofttranslator.com. Here I found a pretty extensive write up on how to maximize your memory usage for your environment. On my system I have a 64 bit processor, so the good ole /3G boot switch is not needed. I’m mainly interested in getting my 32 bit process to beef itself up. Part way down they talk about how processes can be flagged to allow them to allocate into higher address ranges. Sure enough I inspected FlashBuilder.exe with ExeInfo and it didn’t have the flag set to address higher memory ranges. So I backed up FlashBuilder.exe, and per their suggestion, and arguably at my own risk, I used editbin to add the extended memory flag. There are links on the web page on where you can get editbin, but it is a utility that comes with Microsoft’s Visual Studio IDE from roughly 2005 all the way up to 2012
After adding the flag to the executable I was able to use the following settings in my FlashBuilder.ini file:
-Xms1720m -Xmx1720m -XX:MaxPermSize=256m -XX:PermSize=64m -XX:+UseParallelGC
That is the current max, much like my 1024M was my previous. I will probably drop it back some if I start to see odd behavior. But for now it should be okay, and seemingly worth it so far. Wow, quite the performance boost in the IDE. Even startup of Flash Builder has improved greatly. Clean builds are faster, and exporting the final build is faster as well.
As a side note, before today I had to use Firefox on my Windows 8 box, because Microsoft didn’t have the debugger version of flash player available for download. After installing it and switching back to IE 10, memory usage of the IDE was decreased too.
Hope this info is helpful, and I’ll be sure to update this post if this flag starts to have adverse affects in the IDE.