What does it mean to call methods directly, not through a link?

Question

I just watched Grant Skinner 's slideshow of ActionScript productivity gains. One piece of advice he gave was written as follows: "Call the methods directly, not through a link." I don’t quite understand what this means ...

Does it make sense to avoid calling a function for a variable that references a function object?

var someObjectsDoSomethingMethod:Function = someObj.doSomething; someObjectsDoSomethingMethod(); 

Or to avoid calling a function for a variable that references another object that has this method?

 var someObject:Function = someObj; someObject.doSomething(); 

Or...?

Answer 1

You are on the right track, he says that if it is possible (especially for method calls inside loops), the fastest way is to not use the method call at all (see Slide 51), but if you need to try to directly call the method (slide 52 ) Although this is not always practical or desirable, there is some overhead depending on how you call the method and which object you call it.

The biggest damage is that closing is really expensive.

For instance:

 WithAnonymousFunction.Go(function() { /* Do Work */ }); // Slow WithReference.Go(new WorkerClass()); // Faster WithAnonymousReference.Go((new WorkerClass()).doWork); // Faster WithMethod.Go(); // Even faster! WithInlinedMthod.Go() // Fastest! public class WithAnonymousFunction { public static function Go(func:Function):void { func(); } } public class WorkerClass { public doWork() { // Do Work } } public class WithAnonymousReference { public static function Go(func:Function) { func(); } } public class WithReference { public static function Go(cls:WorkerClass) { cls.doWork() } } public class WithMethod { public static function Go() { doWork(); } public static function doWork():void { // Do Work } } public class WithInlinedMethod { public static function Go() { // Do Work } } 

One thing I'm not sure about is the performance difference between a particular class and interface.

Answer 2

 var someFunction:Function = function():void{} 

will run slower than

 public function someFunction():void{} 

Whether the difference is enough that it matters is a completely different story. I think that in the use of variables with typed variables, temporary callbacks for “events” (Not Flash AS3 Events, but the general meaning of the word “event”) are important, which do not occur once in an update cycle. Even inside the update cycle, this strategy is much more convenient to use than using the Flash-based event dispatch model (especially if you use event bubbles, which is an absolute pig).

Of course, it can also refer to Demeter’s Law, which is a means of encapsulating deeply nested is-a relationships, so you don't care if doFoo () requires 10 references to objects and functions calls under the hood while foo is running . Demeter's law can be very intense depending on how deep the call stack is when you call doFoo ().

As for the question in your comment, it's easy enough to check yourself. In fla:

 // on frame 1 var textField:TextField = new TextField(); this.addChild(textField); var f:Function = this.stop(); var i:int = 0; var ilen:int = 100000; var time:int; time = getTimer(); for(i = 0 ; i < ilen ; i++){ f(); } time = getTimer() - time; textField.text = "f() :: "+String(time)+"\n"; this.gotoAndStop(2); // on frame 2 var mc:MovieClip = new MovieClip(); time = getTimer(); for(i = 0 ; i < ilen ; i++){ mc.stop(); } time = getTimer() - time; textField.appendText("mc.stop() :: " + String(time)); this.stop(); 

I have not tested this, so there may be syntax errors. Of course, you will need the right imports. This should be logical.

Be sure to check this out in the browser, not just the debug player or the preview player. Your browser plugin will have higher performance, as well as, most likely, what the end user has on his machine.