There have been some posts by Sho and Grant regarding the relative speeds of int, uint, and Number in AS3. Very interesting stuff, and important to know for the professional programmer. But Tink brings up some good points about the value of using the correct types for the job, regardless of the performance differences.
While I respsonded on Tink’s blog, I wanted to expand my thoughts on it a bit. There’s been a lot of optimization tips and tricks for Flash and ActionScript listed over the years. Granted, in the early days, when the player performance was a fraction of what it has become, these were even more vital than they are now. While some of these go hand in hand with best coding practices, some violate them to the point of becoming code obfuscation. For example, using a decrementing while loop, rather than a for loop to go through a sequence, or using very short variable names, rather than longer, descriptive ones.
Yeah, these things may save you a few milliseconds here and there, but in addition to the headaches they may cause you and other developers down the line, they may wind up actually costing you performance in the long run. I quote from one of my favorite books, Refactoring: Improving the Design of Existing Code, by Martin Fowler:
“A common concern with refactoring is the effect it has on the performance of a program. To make software easier to understand, you often make changes that will cause the program to run more slowly. This is an important issue. I’m not one of the school of thought that ignores performance in favor of design purity or in hopes of faster hardware. Software has been rejected for being too slow, and faster machines merely move the goalposts. Refactoring certainly will make software go more slowly, but it also makes the software more amenable to performance tuning. The secret to fast software, in all but hard real-time contexts, is to write tunable software first, and then to tune it for sufficient speed.”
Fowler then goes on to describe three methods of writing fast software. The first is time budgeting, used for hard real-time systems, such as pacemakers, usually overkill for most information-handling programs.
“The second approach is the constant attention approach. With this approach every programmer, all the time, does whatever he or she can to keep performance high. This is a common approach and has intuitive attraction, but does not work very well. Changes that improve performance usually make the program harder to work with. This slows development. This would be a cost worth paying if the resulting software were quicker, but usually it is not. The performance improvements are spread all around the program, and each improvement is made with a narrow perspective of the program’s behavior.”
This is using Numbers instead of ints. Yeah, you may save 30 milliseconds in your theoretical 16 million iteration loop, but there are probably things happening in the bigger picture that will dwarf that time savings.
“The interesting thing about performance is that if you analyze most programs, you find that they waste most of their time in a small fraction of the code. If you optimze all the code equally, you end up with 90 percent of the optimizations wasted, because you are optimizing code that isn’t run much. The time spent making the program fast, the time lost because of lack of clarity, is all wasted time.”
“The third approach to performance improvement takes advantage of this 90 percent statistic. In this approach, you build your program in a well-factored manner withouth paying attention to performance until you begin a performance optimization stage, usually fairly late in development. During the performance optimization stage, you follow a specific process to tune the program.”
Fowler then describes the optimization process – using a profiler to find the “performance hot spots”, those points in the program that are using up the most cpu time. If it comes down to the point where your uints are causing a bottleneck and changing them to Numbers is really the biggest performance increase you can make, then my hat is off to you, because you must have created the most perfectly optimized program ever. In real life, however, I bet you are going to find much bigger and more serious problems with your own code being inefficient – intervals and enterframes and listeners being called when they don’t need to be, loops continuing when they could be exited, inefficient server calls, etc., etc., etc. Your ints are going to be a non-issue in comparison.
Now, to be honest, I’m not really too up on what resources are available for ActionScript profiling, but I know stuff exists out there, and I’ll leave it to you to dig it up and put it to use. And I figure those who know will be nice enough to post some cool links in the comments.
Personally, though I haven’t been using a profiler, I still do a kind of informal version of the third approach. Basically, I don’t worry about optimization until optimization becomes an issue, then I optimize the areas of the app that aren’t performing well. Not very scientific, but it has worked out pretty well for me. Anyway, I think I just convinced myself to look into profilers. 🙂
Thanks for expanding on this Keith!
Macromedia had a profiler for flex 1. See this page:
http://www.adobe.com/devnet/flex/articles/profiler_04.html
I wonder if they’re going to update it for flex 2, or maybe it still works, I dunno 🙂
Its definitely something I’d use. I’ve tried an actionscript approach but it wasn’t very accurate.
I’ll be the first to admit there is a certain useless, geeky satisfaction that comes from knowing that uints are 5-10 times slower than ints. But I think it’s also important in a very real sense to do those kinds of ‘theoretical’ tests while the new runtime is still in pre-release, so that the player team is aware of any potential bottlenecks and can tune them accordingly – that’s the spirit in which I took Sho & Grant’s discussion. A few hundred milliseconds over 16 million iterations is not a lot by ActionScript standards, and it’s really a testament to the power of AS3 that it’s being talked about at all.
While I agree with your point about variable names, I disagree with the notion that using ‘do…while’ in place of ‘for’ loops is an undesirable practice. For me, its standard practice, and one of the first things I learned in JavaScript class back in the day.
All that aside, you have some really great points regarding performance tuning. In my own work, I follow the same basic pattern of hitting the biggest cpu hogs first. I also sometimes take the additional step of obfuscation, which can automate the process of shortening variable names, making it much more practical in that you’re not muddling your codebase, just creating a release build.
Tom, yeah, I’m not knocking Sho or Grant at all. Like I said, it’s valuable data to have, I just disagree that we should throw ints out the Window because “they will slow down your app” or something like that.
I know the reverse while loop is not the best example, but I still think that:
for(i=0; i
for-loop variables should always be int’s, regardless of optimization. It’s a mental thing. They should be thought of as integers, not floating point numbers. You won’t be tempted to do any floating-point math on the counter if it’s an int.
There’s also that nagging question of what happens when, through round off error, the counter is 5.99999 instead of 6.0. Will the loop have an extra iteration? Probably not — I think Flash has an internal “close-enough” concept, but when I was new to Flash, it did bug me. With an int, there is no question.
So when you’re talking about for-loop variables, array indexes, movieclip depths, names generated from numbers (“mc_” + i), etc., int’s are better than numbers — semantically speaking.
Agreed Joel. int states the intention of the variable in those cases. Technically, uint would be even better, since a lot of those things are not supposed to go negative.
Hi folks.
Great points!
The main reason I wrote my article is that I saw people using ints primarily for two reasons: (1) because they thought they were faster. (2) because they thought they were less prone to roundoff error (e.g., the 5.99999 vs 6.0 issue that was brought up above). As it turns out, neither is true, in the sense that Number can represent integers exactly for a much larger range of integers than the int type can.
There is, of course, a very valid reason to use ints, which is to express the intention of the programmer. I’m glad you wrote your article, because I didn’t make that very clear in mine. This is especially true in API design. Having a function foo(i: int) is very different that foo(x: Number).
The point about loop variables is a bit moot, since making them Numbers doesn’t actually make them faster. It’s really when you’re doing computations (like multiplications, divisions, etc) where the performance characteristics change.
BTW, using uint in a loop variable can be very dangerous if you forget what you’re doing. For example: for(i=foo; i >=0; i–) will never terminate.
Anyway, thanks for your article!
Sho, thanks. I didn’t mean to criticize your article at all. Data like that is vital to know and helps to understand the inner functioning of the flash player. Please post more stuff like that. I just wanted to make sure people didn’t take it and go the opposite direction and start a “ints are evil” campaign. 🙂
I have used reals (Number) for iterations in the past because I wanted to use the value to do other than integer actions, such as creating a list of numbers in tenths in an array.
Just pointing out that all rules have exceptions.