kuwamoto.org

As you have probably heard, Flex 2 has been released. Everyone here is tired and excited. We have been working on this for a long time, and it is great to finally have it out there.

For those of you who have been following the public releases of Flex, the final release will not hold much in the way of surprises (although I will point out a few of my favorite changes below). However, if you step back a minute, the differences between Flex 1.5 and Flex 2 are pretty major. Imagine, if you will, that we had not done any public betas, and that all this news was coming at once:

• Brand new language based on the current draft of the ECMAScript Edition 4 spec that combines strong typing with the dynamic nature of JavaScript
• Completely rewrote the VM to be a modern, JIT compiled engine that runs 5-10x faster than before
• Reworked the framework to be more consistent, and thus easier to extend and subclass
• Added lots of new capabilities to the framework, including state management, transitions, new components, etc.
• Created a brand new tool based on Eclipse
• Decided to give the SDK away for free
• Decided to price the tool at $499 instead of the rumored $999
• Decided to give an express version of FDS

I don’t know about you, but I’m pretty excited by Flex 2, and I’m very curious to see what people will build with it.

Ok. On to my favorite changes since beta 3.
More »

After my post, Grant Skinner did some experiments around the discrepancy between Number and int performance. He originally posted a basic test, but has since expanded his testcases to show how different mathematical operations perform.

You can see his results here.

The more I play with Flex, the more I learn, and the more I learn about ints, the less I want to use them. I’ve concluded that I’m going to stop using ints unless I really need them.

Reason 1: Numbers may actually be faster than ints

Surprising, but true. ECMAScript Edition 4 is designed to be a language that is as compatible as possible with earlier versions of ECMAScript. As it turns out, this makes it difficult to ensure that math works “correctly” in seemingly innocuous cases.

public function timingTest() : void
{
	var intTime : Number;
	var numberTime : Number;
	
	var i : int;
	var j : int = 0;
	
	intTime = (new Date()).time;
	for (i=0; i<10000000; i++)
		j = (j + 15) / 7;
	
	intTime = (new Date()).time - intTime;
	
	var n : Number;
	var m : Number = 0;
	
	numberTime = (new Date()).time;
	for (n=0; n<10000000; n++)
		m = (m + 15) / 7;
	
	numberTime = (new Date()).time - numberTime;
	
	var message : String = 
		"int version: " + intTime + "ms\n" +
		"Number version: " + numberTime + "ms";
	
	Alert.show(message);
}

Which version do you think wins? On my machine, the int version takes 331ms, while the Number version takes 291ms. Why is this? Let’s look at the following expression:

j = (j + 15) / 7;

What happens if you start with the value j = 2^31 – 1? In some languages, you would run into overflow issues as soon as you add 15 to it. ECMAScript, however, has a looser concept of numbers. The system is supposed to move smoothly from ints to doubles as needed. Because of this, virtually all math is done internally as Number, not as int.

Given that everything is being done as a Number anyway, the extra cost of converting from int to Number and back again takes even more time, which is why the int version is slower.

There is a second counterinuitive reason for using Number over int, which is that Number actually lets you store integral values more precisely than ints do…
More »

Sometimes, when you try to start a debug session in Flex Builder, the tool will hang for a long time for no apparent reason. What is actually happening is that the connection between the IDE and the debug process is having trouble getting started, and the system is waiting for the connection to timeout.

You can shortcut this process by explicitly killing the hung process and restarting the debug session.

Step 1: Check to see if you have a task which is stuck by looking in the bottom right corner of your IDE window. There should be a small progress bar with a weird icon next to it. Click on the weird icon to open the progress view.

Step 2: Click on the stop button for the task that is stuck.

That’s it!

Hi folks.

A while ago, I posted an entry about some usability subleties I encountered in tweaking the sliding drawer components. I’d neglected to update the examples in that article for beta 3, which means that the entire article was kind of pointless. I ask people to judge how much better or worse various tweaks are, but you can’t run them!

Several people have bugged me about this, so I’ve updated the examples to run in beta 3. If you’re interested in usability, the article can be found here.