Flex: overhead of new objects construction

Once not a while ago we had a performance troule in the flex application we were developing.
That application handles a lot of data which it needs to get from the server, to prepare and render to the user. And that all stuff was quite slow. So we decided to make everything possible to optimize.

Internally this bloody thing distributed all operation between frames rendering and a kind of a process has been implemented that did a chunk of work betwen 2 sequential frames. Usually such things are implemented using some kinds of timers.

Timers in the code we’ve got were abstractly based on Date.time. We just substitutet all new Date() to getTimer().

That time it seemed to me like it will give almost no optimization but after I’ve profiled results some numbers changed my mind a bit.

Today I decided to check espacially on a simple example how much processor time I can save when eliminating unneded construction of such simple at the first look objects as Date-s are.

Test application is following:

<?xml version=”1.0″ encoding=”utf-8″?>
<mx:Application xmlns:mx=”http://www.adobe.com/2006/mxml” layout=”absolute”>
<mx:Script>
<![CDATA[
import flash.utils.getTimer;

function buttonClickHandler(): void
{
resultsScreen.text = String (doALotOfStuff());

}

function doALotOfStuff(): int
{
const TIME_FRAME: int = 10;
var start: int = getTimer();
var finish: int;
var a: Date = new Date();
var b: Date = new Date();
var idleString: String;
for (var i: int =0; i<100; i++)
{
a = new Date();
b = new Date();
while (b.time - a.time < TIME_FRAME){
for (var idle: int = 0; idle < 10; idle++)
{
idleString = new String("I'm here to fill the gap");
idleString = "";
}
b = new Date();
}
}
finish = getTimer();
return finish-start;
}
]]>
</mx:Script>
<mx:HBox>
<mx:Button
click=”buttonClickHandler()”
label=”Start”/>
<mx:TextInput id = “resultsScreen”/>
</mx:HBox>
</mx:Application>

As you may see it just simulates the process stuff.  It must repeat 100 cycles of some activity, each cycle should fit into 10 milliseconds. So, if everything will cost us no overhead we’d get ~1000 milliseconds as the time needed to work everything out. Real number is ~1560 milliseconds. So nearly 30% of time was eaten by flash player itself to arrange that timing.

In second version (improved) of this simple test application I’ve changed all Date().time to getTimer().

The result was always ~1005 milliseconds.

Well… it’s about 100 times win for arrangement of time-framing stuff.
The conclusion is simple and clear for everyone I believe.