betabits

I went down a few algorithmic roads recently, digging into path finding and – for some obscure reasons – bit manipulations. Or byte. Whatever.

Along this way some utility methods (or functions) were born, and I thought: May be some day some of them may be in use to any of you ;)

For my dear non-geeky readers: A bit is the smallest part in software. It’s either this or that, either 0 or 1, either false or true. With a group of 2 bits you already have 4 states: 00, 01, 10 and 11. With 8 it’s 256 and so on (2^n).

As it would be too boring to just type 0 or 1, and because we have more than 2 fingers, man invented numbers to accumulate these bits: so 9 stands for 1001, and because 9 is shorter than 1001, we prefer 9. Some even write AB for 10101011, but that’s where we come back to geeky world.

So after this highly informative introduction, let’s get to some code. First, let’s count bits:

static public function countBits( value : uint ) : uint {
	var count:uint = 0;
	while (value) {
		if ( value & 1 ) {
			count++;
		}
		value >>>= 1;
	}
	return count;
}

Example:
countBits( 0xAB ) -> 5

Now sometimes you might wanna know: Does this data contain no more than 1 bit? We could just ask countBits( value ) == 1. But that’s not as speedy as it should be, right? So here we go:

static public function is_1_bit( value : uint ) : Boolean {
	var count:uint = 0;
	while (value) {
		if ( value & 1 ) {
			if (count == 1) return false;
			count++;
		}
		value >>>= 1;
	}
	return count == 1;
}

Examples:
is_1_bit( 0xAB ) -> false
is_1_bit( 0×400 ) -> true

uint are by the way 32bit data, so a maximum of 32 of these bits we’re talking about can be turned on or off. That’s a lot of data. 4′294′967′296 combinations (though not that high compared to the numbers we read every day in the newspapers recently). Anyway, sometimes we might wanna access and set only a group of bits (usually 4 or 8) within this quite large row of bits:

static public function getBitGroup( value : uint , group : uint , len : uint = 4 ) : uint {
	return ( value >> (group*len) ) % (1 << len);
}
 
static public function setBitGroup( value : uint , groupValue :uint , group : uint , len : uint = 4 ) : uint {
	var pos:uint = group * len;
	var mask:uint = n_bits(pos);
	var right_bits:uint = value & mask;
	value >>>= pos + len;
	value <<= len;
	value |= groupValue;
	value <<= pos;
	value |= right_bits;
	return value;
}

Don’t they look just groovy?! Yeah baby!

Anyway, that’s all for now. Stay tuned for some crazy path finding. If I find time (sometimes I wonder how all those bloggers find their time to write so much..) Not to mention Twitter. Boohaa.

Sometimes you need to test your Flash stuff with different plugin versions. Even if you just want to run some performance tests, it is very useful to switch to the release player (see below for another example).

For windows there is a neat Firefox Plugin that makes switching quite a snap. On Mac there is one too – I haven’t tested it, but it’s supposed to work (though I’m not too sure about that when I read these comments here). Still I prefer to work with Safari and I kind of dislike the thought of starting Firefox to just switch Plugins.

wspluginswitcher-iconFortunately I’ve found another solution: WSPluginSwitcher. This one comes as a Cocoa app and once configured (you really should read this wiki page), it works real well for me. Also they have prepared plugin versions for you to download (though the most recents are missing, but no big deal really).

As for the speed tests, let me just give you another example (impressing enough for me to wanna switch players for real world testing).

In Debug Player:

method...................................................ttl ms...avg ms
tare [2]                                                      0     0.00
CSSFastParser                                               603   120.60
CSSRegExpParserFast                                         987   197.40
CSSRegExpParserFastAdvanced                                1457   291.40
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

In Release Player:

method...................................................ttl ms...avg ms
tare [2]                                                      0     0.00
CSSFastParser                                               354    70.80
CSSRegExpParserFast                                         972   194.40
CSSRegExpParserFastAdvanced                                1469   293.80
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

Both 10.0.22.87, and exported as release swf. Oh, and by the way tested with another useful tool from Grant Skinner: AS3 Performance Testing Harness.

I did some speed tests today, comparing two string parsing methods. And I’ve made some very interesting discoveries: The execution speed between SWF compiled for debugging and those compiled without differs.

Ha! Okay, that’s not that much of news (even for me). But what astonishes me is how much this speed gap can be, especially when it comes to massive data calculations. I somehow always had a somewhat 20 percent speed decrease in mind (I was just presuming, me dumb). But for a 3d particle test we’re talking factor 8!!

Now this made me curious… so I’ve tested with Debug and Release Player both debug and release SWFs:

Debug Player running Debug SWF

Flash Debug in Debug

Debug Player running Release SWF

Release in Debug

Release Player running Debug SWF

Debug in Release

Release Player running Release SWF

Release in Release

A few conclusions:

  • Never release a SWF file with debug code (or otherwise said: put only stuff online from bin-release, never bin-debug). Though common users won’t notice the speed decrease, your friendly flash developers may, at least if you’re app is somewhat cpu intensive. And of course: debug SWF are much bigger in size (just in case you give a fuck about flash devs ;-)
  • Speed tests should be played in the release player. Why? After all, I wouldn’t care if the relation would stay the same. Usually you just need to know how much faster one thing is compared to the other one, so that would do it. But unfortunately the ratio won’t always be the same. In the above example the ration is 3.66 for debug and 2.92 for release. And it can differ muuuuch more.

The last one bugs me quite a bit. It’s just a pain in the ass to export a release build each time you wanna compare performance. And it also means you can’t do quick’n'dirty trace outputs for the time result (not a biggy if you’re testing within a Flex project though).

So here we go with two wishes for Adobe:

  • Let us quickly test release builds within Flex Builder (a simple command would do it – I thought it might be «Run Testapp» (instead of «Debug Testapp»), but that just doesn’t bring up the Debugger (and same speed)
  • An option to turn off debugging mode in Debug Player!!! That would solve almost all problems, and we could also use our Plugin for normal browsing without performance penalties (is this why Youtube eats so much cpu here?

In my current project I do a lot of String parsing. Much a lot! And when it comes to do the same things many many times, performance will gain much from little details.

Let’s take the simplest parsing as an example. Converting a CSS like string “width: 100%; maxwidth: 500; fontface: Bold; gap: 10;” to an object { width: “100%” , maxwidth: “500″ , fontface: “Bold” , gap: “10″ }

Compare these two methods to achieve this:

public static function simpleStringToObject_fast( input : String , o : Object = null ) : Object {
	if ( input == null || !Boolean(input) ) return o;
	if ( o == null ) o = {};
 
	var cursor : int = 0;
	var found_key : String;
	var index : int;
	while ( true ) {
 
		if ( found_key == null ) {
			index = input.indexOf( ':' , cursor );
			if ( index &gt;= 0 ) {
				while( input.charAt(index-1) == ' ' ) index--;
				found_key = input.substring( cursor , index );
				cursor = index + 1;
				while( input.charAt(cursor) == ' ' ) cursor++;
			} else {
				break;
			}
		} else {
			index = input.indexOf( ';' , cursor );
			if ( index &gt;= 0 ) {
				while( input.charAt(index-1) == ' ' ) index--;
				o[ found_key ] = input.substring( cursor , index );
				found_key = null;
				cursor = index + 1;
				while( input.charAt(cursor) == ' ' ) cursor++;
			} else {
				o[ found_key ] = input.substr( cursor );
				break;
			}
		}
	}
 
	return o;
}
 
public static function simpleStringToObject_slow( input : String , o : Object = null ) : Object {
	if ( input == null || !Boolean(input) ) return o;
	if ( o == null ) o = {};
 
	input = input.split(' ').join(''); // remove spaces
	var a : Array = input.split(';');
	var pair : Array;
	for ( var i:int=0 ; i 1 ) {
			o[ pair[0] ] = pair[1];
		}
	}
	return o;
}

The first one might look like some crap lacking any elegance and style, but it’s twice as fast as the second one! And hey, if you do this a million times, it can be 5 seconds instead of 10. Might not seem to be that much, but I think it’s certainly worth the extra coding :-)

(Update: I haven’t mentioned RegExp here, though it definitely deserves a mention. Thing is that Regular Expressions are just damned slow in Flash compared to String manipulations, especially with longer strings. This is kind of surprising because it’s implemented natively. But the implementation obviously isn’t too good performance wise. I hope to see improvements with F10, though haven’t read anything about it yet – and also haven’t tested yet with beta. This little article confirms my experience with RegExp: With a file of 10,000 lines, the string version is still instantaneous, but the regular expression version takes about five seconds. Even with 180,000 lines, the string version is immediate. We gave up on the regular expression version after over five minutes..)

So Flash Player 10 is on its way. Soon, very soon, we’ll be able to enjoy 3D effects on every other website, youhaa. While some are eagerly waiting for this or the enhanced drawing API, I’m very much looking forward to the speed enhancements.

Visual Speed

While Flash Player 9 or more precisely the underlying actionscript 3 interpreter have lead to great speed enhancements on the logic side (meaning much faster data manipulation), it’s still rather slow when it comes to rendering. In a project I’m currently working on there’s quite some stuff going on here, but when I check speed performance with the Flex Profiler, most time is spent for rendering. Significant time. And it’s not some freaky Papervision 3D stuff ;)

So with Flash Player 10 this will be better. Adobe finally improves rendering speed, and the good thing is that every exisiting project (at least >= f9, all?) will profit without republishing. I had done some little tests with a beta, and though I don’t remember the results, they looked quite promising (even on a Mac). I’m not sure though when they’re gonna use the graphic card to speed up – I don’t think it made use of that in my tests. Most people mention the hardware acceleration (some rendering tasks can be offloaded to your graphics card), but in my understanding the overhauled the entire rendering system, so everything and everyone should profit.

Vectors

Vectors are simply typed Arrays. A limited array. Ha! why would we want that?! For two reasons:

  • Developers have more feedback while coding: the IDE will be able to tell you when you put some wrong stuff in an array – as for now you could mix whatever data in an array, the compiler wouldn’t complain. But above all, the IDE will be able to provide you help while typing: no more casting all the time to get to the methods of an array item!
  • Speed. A typed array can be much faster. And it will be.

It looks like this:

var vector:Vector.&lt;int&gt; = new Vector.&lt;int&gt;();

I’m not too much a fan of the definition syntax – something like this would look better, I think:

var vector:Vector::int = new Vector::int();
// or
var vector:int[] = new int[]();

But I haven’t thought of it much. Adobe certainly thought about it. Or some ECMA comittee. (Copy-pasting in Wordpress HTML mode also won’t work anymore.. pfff) Also I personally would have preferred not to have another class for that (just enhance the good old Array), but there are reasons for that too (backward compatibility, I guess, I can sing a song about that too). So anyway, I’m eagerly looking forward to use that stuff. I just love speed.

More infos here: Using Vectors in ActionScript 3 and Flash Player 10

Update: Ok, I can’t make to appear the new Vector syntax in Wordpress. Now I like the syntax even less ;-)