Includes some 10.3 results (which you missed doing an update on). Should get a really good representative sample of performance across platforms and CPUs (some really high end machines, low end machines like mine, various windows versions, linux. maybe some macs).

I just did the test to find out if caching apple/call would result in a speed up (in FP11: no. apply/call are the same speed as a dynamic call when using the dot notation). I just did a test, added the missing ones and graphed it, here: http://i.imgur.com/9ElgF.png with the code: http://pastebin.com/gyQ9swJD

Something like this:

objectInstance["functionName"](param1, param2, ...);

Too slow?

As for your test results, they’re pretty much the same as my results except for the getters and setters. Keep in mind that the iPhone 4 is running a single-core 800 Mhz ARM chip and my test machine in the article was a 3.0 Ghz Intel Core 2 Duo. The iPhone’s also got an 800 Mhz memory bus compared to the 1066 Mhz dual-channel memory bus on the desktop test machine. Given such a huge hardware advantage on the side of the test machine from the article, I don’t think it’s so unreasonable to expect an order of magnitude less performance out of the iPhone. Still, you’re seeing a ~50x slowdown, so there’s a good chance that more is going on here. Perhaps the compiler used to compile the Flash Player VM is not as optimized for ARM as it is for x86. For example, Flash Player may be compiled with Intel’s highly-optimized compiler when targeting x86 and the much-slower GCC may be used when targeting ARM. Together, these hardware and software differences alone may be responsible for the difference.

Thanks for the performance numbers!

Again this is still with NUM_ITERATIONS set to 1000000, one order of magnitude. I have triple checked and this is now consistent with all tests – what I’ve done is set NUM_ITERATIONS as a local const and then done a local function ‘cache’ as you illustrated in your linked post where within the function, eg:

private const NUM_ITERATIONS:int = 1000000;
 
private function testDynamicFunctions(ev:Event): void
{
    const NUM_ITERATIONS:int = this.NUM_ITERATIONS;
    var beforeTime:int;
    var i:int;

I humbly and profusely apologize for the horrible misinformation prior. It is still disappointing, however the performance drop is not nearly as jarring as before!

Plain: 6660
Local: 2335
Function var: 2307

Private: 245
Protected: 241
Internal: 238
Public: 247

this.Private: 237
this.Protected: 241
this.Internal: 238
this.Public: 232

Static private: 354
Static protected: 268
Static internal: 271
Static public: 261

Override protected: 236
Override internal: 246
Override public: 242

Super protected: 227
Super internal: 282
Super public: 294

Interface direct: 226
Interface via interface: 276
Interface via class: 222

Private Get: 234
Protected Get: 225
Internal Get: 222
Public Get: 222

Private Set: 2489
Protected Set: 5797
Internal Set: 2382
Public Set: 2505

Final Private: 244
Final Protected: 252
Final Internal: 288
Final Public: 352

Final Override protected: 226
Final Override internal: 223
Final Override public: 224

I performed these tests three times. Once I saw an anomalous doubling of this.Private, but that did not occur 2/3 times. However Protected Set is consistently twice as slow as its Internal, Private and Public counterparts.

1) Make sure you’re using a release build. ActionScript typically runs 2-3x slower in debug builds.
2) A static field lookup every loop will be very expensive and greatly increase loop times overall. It’s annoying to have to keep declaring NUM_ITERATIONS locally, but local variable lookup is really worth it.

Hope that helps.

1) The NUM_ITERATIONS was made into a private static const.
2) NUM_ITERATIONS was DECREASED by an order of magnitude. Execution times were still abysmal.

Plain: 19886
Local: 16043
Function var: 16187

Private: 5584
Protected: 5622
Internal: 6017
Public: 6492

this.Private: 5524
this.Protected: 5624
this.Internal: 5780
this.Public: 5662

Static private: 5818
Static protected: 5632
Static internal: 5638
Static public: 5743

Override protected: 5856
Override internal: 5911
Override public: 5695

Super protected: 5674
Super internal: 5853
Super public: 5901

Interface direct: 5510
Interface via interface: 5550
Interface via class: 5514

Private Get: 6563
Protected Get: 6172
Internal Get: 5844
Public Get: 5644

Private Set: 16141
Protected Set: 18751
Internal Set: 16383
Public Set: 15935

Final Private: 56311
Final Protected: 56317
Final Internal: 56242
Final Public: 56032

Final Override protected: 56237
Final Override internal: 55356
Final Override public: 55609

Built for iOS from Flash Builder 4.5.1 targeting AIR 2.7. Interestingly this flies completely in the face of the optimization ‘wisdom’ preached by Adobe themselves. And no, those last results aren’t typos, I had to wait several minutes before I saw any results.