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. 🙂