Comments on: Case Study : ActionScript 3 Performance Optimization

By: Ben Garney

Ben Garney — Wed, 14 Oct 2009 07:14:01 +0000

Andre mentioned this, but what is the diff for release vs. debug player running this code? In my experience, you can see massive differences between the two.

By: mikechambers

mikechambers — Wed, 14 Oct 2009 02:52:19 +0000

@David

Yeah, you are right. Count is not needed at all. That was left over from the original code.

You could just len.

Good catch.

mike chambers

mesh@adobe.com

By: David Wilhelm

David Wilhelm — Wed, 14 Oct 2009 00:52:21 +0000

Do you really need the ‘count’ variable at all? isn’t it just duplicating ‘len’ = pixels.length ? If so then you could remove one statement from the loop.

By: Renato Moya

Renato Moya — Wed, 14 Oct 2009 00:19:14 +0000

Interesting post, Mike.

Well, I believe it would be essential that all these tricks to improve performance get done by the compiler for mobile applications ONLY.

I understand it sounds nuts writting instructions to the compiler to every single bad coding case in order to keep the code appearance and make life easier to developers.

I believe the flash team is doing a great job already by sharing these tricks, tips, tests, etc to the community, this is something we should learn, not to ask the compiler to do it for us.

By: neon::pixel

neon::pixel — Tue, 13 Oct 2009 18:41:44 +0000

Hello!
This can be a dumb question. If you’re saying that “Some operations are faster in DebugPlayer than ReleasePlayer”! So how about using an external bebugger? Like Alcon maybe? Just asking :S

By: Andre Michelle

Andre Michelle — Tue, 13 Oct 2009 18:27:34 +0000

@Mike

“However, I was trying to focus on improvements that I could make to the code today.”

Yeah, that is our daily bread. Workaround the bad compiler. Spending a huge amount of time. I just wanted to point out, that a new compiler would make a difference in future for everybody, not just for cutting edge guys.

@everyone

Please vote > http://bugs.adobe.com/jira/browse/ASC-3802

By: mikechambers

mikechambers — Tue, 13 Oct 2009 18:22:50 +0000

@Andre

Yes. I saw Joa’s session at FOTB and Max, as well as met with him a couple of times about his work.

I, and the compiler team, are aware of the improvements that could be made in the compiler. However, I was trying to focus on improvements that I could make to the code today.

mike chambers

mesh@adobe.com

By: Andre Michelle

Andre Michelle — Tue, 13 Oct 2009 18:21:55 +0000

@Mike:

“What types of improvements are you seeing?”

Have you tried to test it the way I propose?

If you still don’t get a big performance peak, I will try it tomorrow. Maybe things have change in the last update.

By: Troy Gilbert

Troy Gilbert — Tue, 13 Oct 2009 18:19:32 +0000

@Mike: I’m guessing the difference between for each and for is down to the “proxy” function call overhead? I would think this could be optimized-out by the compiler with a vector, but it wouldn’t surprise me if it’s not.

What I mean: when calling for each, the runtime is internally calling getNextName() (or whatever the proxy iterator function is) on the object. These would be unnecessary for direct indexing.

By: Andre Michelle

Andre Michelle — Tue, 13 Oct 2009 18:16:57 +0000

“In my case, the gains were not enough to justify making the code less readable.”

Imagine you could do this:

Instead of
[red += pixel >> 16 & 0xFF;]
you write
[red += pixel.getRed();]

That is readable code. A usual compiler would fix the optimization for you by inlining the code from the method call. That is what Joa is about to do in Apparat > http://blog.joa-ebert.com/2009/08/11/apparat-is-now-open-source

We are so used to write optimized code, that we forgot how it could be. Not to mention bigger projects, where readability suffers when trying to make things fast. And not to forget Actioscript beginners, who have no clue at all, that optimization exists.