bytetrap

Lazy Evaluation in AS3

Lazy evaluation is a useful practice for any programmer who wants to cut down on unnecessary processing. There's no need to break it out if it's not necessary; especially if the language (Actionscript) is ill suited to it. There are cases though where delaying computation until the result is required lets lazy evaluation slice off the extra computational gristle that's slowing down my code.
I ran into a situation a few days ago that really benefited from the lazy approach. I had a class named Vector2 which handled 2-dimension computation, as described below.

//Vector2 with Eager Evaluation
public class Vector2 {
	
	private var _x:Number;
	private var _y:Number;
	private var _length:Number;

	public function Vector2( x:Number = 0, y:Number = 0 ) {
		setXY( x, y );
	}

	public function setXY( x:Number, y:Number ):void {
		_x = x;
		_y = y;
		_length = Math.sqrt( _x * _x + _y * _y );  //length is computed as soon as x and y are set
	}

	public function get x():Number {
		return _x;
	}
		
	public function get y():Number {
		return _y;
	}
	public function get length():Number {
		return _length;
	}
}

The issue arose when dealing with the _length value in a Vector2. The square root in determining the _length of a Vector2 was computationally intensive and often unnecessary. It was a rare occasion when I needed the length of a vector; most of the time I produced vectors for minor computations that never needed a calculation of length. Therefore, I wanted to delay the computation of the length of the vector until it was absolutely necessary.
Simultaneously, I didn't want a getLength() function, because I didn't want to have to recompute the length every time I asked for it. I wanted to compute the length once, the moment I asked for it, and save that result for future references. However, if in the future I changed the _x or _y, I needed some way to tell my program that the length of the vector needed to be recomputed the next time I requested it.
Lazy evaluation magically fulfills all my requirements.

Implementing Lazy Evaluation

Flash is an Eagerly Evaluated language though, how can one implement Lazy Evaluation?

//Vector2 with Lazy Evaluation
//Code not directly applicable to the example has been removed
public class Vector2 {
	
	private var _x:Number;
	private var _y:Number;
	private var _length:Number;
	private var lengthFunction:Function;

	public function Vector2( x:Number = 0, y:Number = 0 ) {
		_x = x;
		_y = y;
		lengthFunction = function() { 
			_length = Math.sqrt( _x * _x + _y * _y ); 
		};
	}

	public function set x( newX:Number ):void {
		_x = newX;
		lengthFunction = function():void {
			_length = Math.sqrt( _x * _x + _y * _y );
		}
	}
	public function set y( newY:Number ):void {
		_y = newY;
		lengthFunction = function():void {
			_length = Math.sqrt( _x * _x + _y * _y );
		}
	}
	public function get x():Number {
		return _x;
	}
		
	public function get y():Number {
		return _y;
	}
	public function get length():Number {
		lengthFunction();    //recomputes the length of the Vector2 if necessary
		lengthFunction = function():void {}    //replaces the length function with an empty function call
		return _length;
	}
}

The Vector2 class written above achieves lazy evaluation through Flash's Function class. When I request the length of my Vector2, the lengthFunction (an object of a function) is called, and the length is returned. The lengthFunction is where all the lazy magic happens.

Whenever the _x or _y value is altered, the lengthFunction is set to Math.sqrt( _x * _x + _y * _y ). Once the length is evaluated however, it reassigns itself to an empty function. Next time I ask for the length of my Vector2, the processor will run through an empty function call rather than the computationally intensive square root calculation.

This class uses a number of getter and setter methods which I have heard are rather slow, but that doesn't detract from the practical merit of this practice. It's like helping a friend move into a new apartment, you have to know when to avoid the unnecessary heavy lifting.

Setting Up a Shared Remote Git Repository

Here is a good article on setting up a new remote git repository. Here are additional steps to create a shared repository which allows multiple users to contribute to the same repository. First, add sharedrepository = 1 in the config file of the repository:

[core]
    repositoryformatversion = 0
    filemode = true
    sharedrepository = 1

Create a new system group for users who should have access to the repository. Add the users into the group:

$ groupadd git
$ gpasswd -a ryan

Next, set up secure permissions on the repository. Start by changing the ownership of the files in the repository to root and the group specified above:

$ cd /var/git/project.git
$ chown -R root:git .

Remove access to the repository from everybody except the user and group:

chmod -R o-rwx .

The group should have the same permisisons as the user:

chmod -R g=u .

Add the s flag on the group permissions for all directories in the repository. This will give processes that tries to access the directories the necessary privileges to add and modify content within the directories. This is necessary to allow multiple external users to commit to the repository:

find . -type d | xargs chmod g+s

That's it. The repository should be set and good to go.

Delay Function Call in AS3

I have a confession to make - I've been seeing another language.
I'm sorry AS3, but Scheme is just so much more elegant that you.

I've decided to focus more on the functional aspects of AS3 after fooling around with Scheme for the last semester or so. All of what I'm about to say could be done with more explicit objects, but I think that would be masking the idea behind this code.

I'm working on a new game where a little man on a raft is hunted by God. God, in his old testament (and vaguely Zeusish) rage, hurls bolts of lightning, summons storms, and calls really enormous fish to smite this poor little dude. I wanted my lightning strikes to come in delayed intervals (first bolt at 1 second, second bolt at 3 seconds, etc... ), but I didn't want to explicitly call a timer every time. I wanted a more general solution to the problem. Then I found out that AS3 was pretty good at passing functions as objects.

Code

The following code sets up our example. Cut and paste it into the timeline to run it.

//Create a new Sprite that is a child of the stage
Var testSprite:Sprite = new Sprite();
addChild( testSprite );

//draw a rectangle in the sprite
testSprite.graphics.beginFill( 0x0000FF, 1 );
testSprite.graphics.drawRect( 0,0, 200 200 ); //the function we're going to delay
testSprite.graphics.endFill()

Now we're going to delay the function call drawRect(...). Replace your previous code with the following.
The Function object has an .apply function, which takes the object the function is called on, and the arguments (in the form of an array) passed to that function.

//Create a new Sprite that is a child of the stage
Var testSprite:Sprite = new Sprite();
addChild( testSprite );

//draw a rectangle in the sprite
testSprite.graphics.beginFill( 0x0000FF, 1 );

//you'll notice that we're not calling the function, just passing its reference.
Var delayFunction:Function = testSprite.graphics.drawRect;  

//the arguments provided for the function
var arguments:Array = [ 0, 0, 200, 200 ];

//a simple timer to delay the function call
var timer:Timer = new Timer( 1000, 1);
timer.addEventListener( TimerEvent.TIMER, runFunction );
timer.start();

//our function that listens to the timer, waiting for it to ring before running
protected function runFunction( event:Event ):void {
			
	delayFunction.apply( testSprite.graphics, args );
	testSprite.graphics.endFill()
			
}

Warnings about this method of programming. Make sure your object doesn't get dereferenced between when you create the function and when it gets applied (that should throw you some errors). Now for the more general case. Here is a little class I programmed that delays function calls.

package {
	
	import flash.events.Event;
	import flash.utils.Timer;
	import flash.events.TimerEvent;
	
	/**
	 * Delays before running the function
	 * @author Daniel Fast
	 */
	public class WaitThenDo {
		
		protected var timer:Timer;
		
		protected var delayFunction:Function;
		protected var args:Array;
		protected var obj:Object;
		
		/**
		 * delay a number of seconds before running the function
		 */
		public function WaitThenDo( func:Function, obj:Object, args:Array, delay:Number, repeat:Number = 1 ):void {
			
			this.args = args;
			this.delayFunction = func;
			this.obj = obj;
			
			timer = new Timer( delay * 1000, repeat );
			timer.addEventListener( TimerEvent.TIMER, runFunction );
			timer.start();
			
		}
		
		protected function runFunction( event:Event ):void {
			
			delayFunction.apply( obj, args );
			
		}
		
	}
	
}

Formatting a USB Stick in Arch Linux

My USB stick goofed the other day. The file system became corrupted and my system had difficulty properly reading from and writing to the device. Fortunately my system was still able to recognize the stick, allowing me to fix it without too much effort. Regardless, I'm writing this short entry on how to format a USB stick because I'm bound to run into this problem again.

Partitioning the USB Stick

The easiest way to fix a corrupted file system is to simply delete the damn partition and start from scratch. You won't be able to salvage any files from the stick but it's a quick and painless solution to have a working device again. First, connect the USB stick into your computer and figure out the device name:

$ dmesg |tail
sd 6:0:0:0: [sdb] Mode Sense: 00 00 00 00
sd 6:0:0:0: [sdb] Assuming drive cache: write through
sd 6:0:0:0: [sdb] 15794175 512-byte hardware sectors: (8.08 GB/7.53 GiB)
sd 6:0:0:0: [sdb] Write Protect is off
sd 6:0:0:0: [sdb] Mode Sense: 00 00 00 00
sd 6:0:0:0: [sdb] Assuming drive cache: write through
 sdb: sdb1
sd 6:0:0:0: [sdb] Attached SCSI removable disk
sd 6:0:0:0: Attached scsi generic sg2 type 0
usb-storage: device scan complete

Then use fdisk to delete all existing partitions on the stick and create a new one. Use the default values when creating a new partition:

$ fdisk /dev/sdb

Now you need to create a new file system. You definitely don't want to use a journaling file system like ext3 because writing to the device will be much slower and some space will be wasted for the journal. Also it will be incompatible with machines using Windows. Use VFAT instead. You will need the dosfstools package to be able to create that file system:

$ pacman -Sy dosfstools

Create the file system on the stick:

$ mkfs.vfat /dev/sdb1

Try mounting the stick. It should work:

$ mount /dev/sdb1 /media/usb

Recovering Data

If you need to recover data, here is an article on how you could possibly salvage the data on a corrupted stick. I haven't tested it so I can't verify how well it works.

Django Benchmark: mod_python vs. mod_wsgi

There are already a couple of articles out there that conclusively state that mod_wsgi has a lower memory overhead and performs better than mod_python. I did a lot of digging around but couldn't find any concrete data on how much performance I would gain by switching to mod_wsgi. Since I was planning on switching over my Django projects anyway, I decided to do a benchmark test to see what the numbers looked like.

Methodology

I conducted the test on my laptop (ThinkPad T60), which has the following specifications:

2.0GHz Intel Core Duo (Yonah) T2500, 2MB of L2 cache
1GB of RAM
Arch Linux 2.6.28 i686
Apache 2.2.11, Pre-Fork MPM
mod_python 3.3.1
mod_wsgi 2.3

I used the base httpd.conf file that came from the default Arch Linux install. The analysis is derived from a load test performed using ab, aka ApacheBench (v2.3). I measured performance in terms of:

Number of requests served per second.
Latency response time in milliseconds.

The demo site used to measure performance is a simple Hello World application, so only static content was used. The load test was run twice, the first time using both mod_wsgi and the second time using mod_python. Each test was run independently and followed these steps:

The machine is rebooted; destroying extranneous child processes created between tests and flushing the memory and cache. It is necessary to maintain consistency across all tests.
Run the load test. Each test starts with 1 concurrent users and the load is increased by intervals of 10 to a maximum load of 200 users. Each interval consists of 5 simulations, and its average is used for the graphs. Each simulation simulates 1000 requests.

Results

Here is the raw data gathered from the test:

Requests per Second (mod_python)

Concurrency	Run 1	Run 2	Run 3	Run 4	Run 5	Average	± σ
1	506.11	513.13	451.93	513.78	460.18	489.03	30.39
10	809.37	889.26	828.37	765.17	764.91	811.42	51.60
20	781.22	814.43	768.44	397.53	911.77	734.68	196.66
30	742.19	779.90	716.17	651.84	690.45	716.11	48.83
40	734.50	723.39	760.76	543.60	418.64	636.18	148.90
50	725.84	704.99	687.82	620.58	694.27	686.70	39.68
60	739.61	742.00	564.42	669.93	697.10	682.61	72.66
70	719.93	741.36	758.58	761.72	603.25	716.97	65.71
80	755.55	608.91	729.43	704.57	641.06	687.90	61.26
90	735.95	710.01	695.61	559.32	387.32	617.64	145.82
100	670.18	634.93	703.91	717.19	661.85	677.61	33.10
110	668.30	696.03	663.72	714.04	685.37	685.49	20.59
120	691.75	702.94	723.24	662.35	467.70	649.60	104.04
130	347.04	725.80	708.91	694.92	716.96	638.73	163.45
140	677.47	690.62	686.36	686.08	723.11	692.73	17.64
150	736.96	730.58	713.07	640.02	546.07	673.34	80.95

Requests per Second (mod_wsgi)

Concurrency	Run 1	Run 2	Run 3	Run 4	Run 5	Average	± σ
1	497.09	508.48	499.23	510.04	505.59	504.09	5.69
10	890.19	845.55	798.46	834.20	844.81	842.64	32.78
20	824.96	700.34	583.10	848.99	810.46	753.57	111.05
30	781.50	825.53	738.09	720.25	740.55	761.18	42.39
40	810.62	792.99	829.81	809.80	830.41	814.73	15.71
50	819.01	827.41	864.42	727.75	799.78	807.67	50.47
60	798.28	626.20	789.92	874.75	749.22	767.67	91.18
70	814.53	803.98	659.83	498.84	784.61	712.36	134.54
80	745.46	627.36	763.28	802.21	777.89	743.24	68.03
90	784.43	783.72	790.53	713.44	478.60	710.14	133.25
100	322.69	826.19	803.53	790.29	837.32	716.00	220.64
110	787.18	761.44	765.44	685.14	759.73	751.79	38.85
120	798.28	789.82	781.68	727.36	780.56	775.54	27.86
130	804.60	808.80	829.83	849.97	744.16	807.47	39.76
140	800.70	691.09	438.41	414.73	621.90	593.37	165.28
150	756.59	747.22	780.77	756.80	799.11	768.10	21.32

Time per Request (mean) (mod_python)

Concurrency	Run 1	Run 2	Run 3	Run 4	Run 5	Average	± σ
1	1.976	1.949	2.213	1.946	2.173	2.051	0.131
10	12.355	11.245	12.072	13.069	13.073	12.363	0.764
20	25.601	24.557	26.027	50.310	21.935	29.686	11.638
30	40.421	38.466	41.890	46.024	43.450	42.050	2.884
40	54.459	55.295	52.579	73.583	95.547	66.293	18.426
50	68.886	70.923	72.683	80.569	72.018	73.016	4.461
60	81.124	80.863	106.303	89.562	86.071	88.785	10.444
70	97.232	94.422	92.277	91.897	116.038	98.373	10.100
80	105.883	131.382	109.675	113.544	124.793	117.055	10.686
90	122.291	126.758	129.383	160.909	232.364	154.341	46.211
100	149.214	157.498	142.063	139.433	151.092	147.860	7.242
110	164.597	158.040	165.732	154.052	160.498	160.584	4.789
120	173.474	170.712	165.921	181.174	256.575	189.571	37.862
130	374.591	179.113	183.380	187.072	181.321	221.095	85.857
140	206.651	202.717	203.974	204.060	193.608	202.202	5.013
150	203.538	205.316	210.359	234.366	274.690	225.654	30.071

Time per Request (mean) (mod_wsgi)

Concurrency	Run 1	Run 2	Run 3	Run 4	Run 5	Average	± σ
1	2.012	1.967	2.003	1.961	1.978	1.984	0.022
10	11.234	11.827	12.524	11.988	11.837	11.882	0.461
20	24.244	28.557	34.299	23.558	24.677	27.067	4.487
30	38.388	36.340	40.646	41.652	40.510	39.507	2.132
40	49.345	50.422	48.204	49.395	48.169	49.107	0.944
50	61.049	60.429	57.842	68.705	62.517	62.108	4.057
60	75.162	95.816	75.957	68.591	80.083	79.122	10.201
70	85.939	87.067	106.087	140.324	89.216	101.727	23.073
80	107.317	127.519	104.811	99.724	102.842	108.443	11.020
90	114.733	114.836	113.848	126.149	188.049	131.523	32.003
100	309.895	121.038	124.451	126.536	119.428	160.270	83.690
110	139.740	144.463	143.709	160.552	144.788	146.650	8.030
120	150.322	151.934	153.515	164.979	153.736	154.897	5.801
130	161.570	160.732	156.659	152.947	174.693	161.320	8.232
140	174.846	202.583	319.334	337.565	225.118	251.889	72.410
150	198.258	200.743	192.118	198.203	187.708	195.406	5.350

And here are the graphs. These are much more telling:

Conclusion

On average mod_wsgi is able to serve 9.6% more requests than mod_python.
The standard deviation for requests per second using mod_wsgi is 6.9% lower than mod_python. This could be due to accident, or this could imply that mod_python is not as stable and consistent as mod_wsgi.
On average mod_wsgi was able to serve requests 8.8% faster than mod_python.
Again, the standard deviation for time per request using mod_wsgi is 5.4% lower than mod_python.

I don't think I can draw any conclusions from the standard deviations without doing a little more testing. But it seems pretty clear from looking at the raw digits and the graphs that mod_wsgi performs better than mod_python. It would be interesting to see how mod_wsgi measures up in a real-world environment.