\n| a += b<\/td>\n | —<\/td>\n | 0.1603<\/td>\n | 0.0092<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n I always assumed that the short hand assignment would be faster since it has one less variable reference. While there is a slight difference in speed, it is less than the standard deviation and all trials have the same maximum. This was true across all computers. The reason that these trials are 10 times slower than the following trials is that the loop is calling a function to avoid boundary issues that would happen with dividing or multiplying a number 1,000,000 times. Division is so costly because of all of the decimal remainders that are calculated for every computation, similarly addition and multiplication do get slower for larger numbers. All of these calculations were with the same 2 digit numbers to have a constant operation speed and isolate speed differences between syntax. Conceivably, there could be a difference in speed dwarfed by the expense of a function call, but that difference would be small enough to treat as insignificant.<\/p>\n Comparing the speed of division, multiplication and bit shifting, 10,000,000 computations per trial. Run the benchmarks: operations with integers<\/a>, operations with numbers<\/a>, operations using numbers and casting<\/a><\/p>\n \n\n\n| <\/th>\n | Division<\/th>\n | Relative Speed<\/th>\n | Average<\/th>\n | Std. Dev.<\/th>\n<\/tr>\n<\/tbody>\n<\/colgroup>\n\n\n\n\n\n\n<\/colgroup>\n | \n\n| Computer A<\/td>\n | a = int(b \/ c)<\/td>\n | + 12%<\/td>\n | 0.1957<\/td>\n | 0.0161<\/td>\n<\/tr>\n | \n| a = b \/ c : integers<\/td>\n | + 23%<\/td>\n | 0.2153<\/td>\n | 0.0096<\/td>\n<\/tr>\n | \n| a = b \/ c : Numbers<\/td>\n | —<\/td>\n | 0.1752<\/td>\n | 0.0064<\/td>\n<\/tr>\n<\/tbody>\n<\/colgroup>\n | \n\n| Computer B<\/td>\n | a = int(b \/ c)<\/td>\n | + 285%<\/td>\n | 0.3005<\/td>\n | 0.0156<\/td>\n<\/tr>\n | \n| a = b \/ c : integers<\/td>\n | —<\/td>\n | 0.078<\/td>\n | 0<\/td>\n<\/tr>\n | \n| a = b \/ c : Numbers<\/td>\n | + 8%<\/td>\n | 0.0843<\/td>\n | 0.0158<\/td>\n<\/tr>\n<\/tbody>\n<\/colgroup>\n | \n\n| Computer C<\/td>\n | a = int(b \/ c)<\/td>\n | + 234%<\/td>\n | 0.314<\/td>\n | 0.0037<\/td>\n<\/tr>\n | \n| a = b \/ c : integers<\/td>\n | + 334%<\/td>\n | 0.4081<\/td>\n | 0.0409<\/td>\n<\/tr>\n | \n| a = b \/ c : Numbers<\/td>\n | —<\/td>\n | 0.094<\/td>\n | 0<\/td>\n<\/tr>\n<\/tbody>\n<\/colgroup>\n | \n\n| Computer D<\/td>\n | a = int(b \/ c)<\/td>\n | + 225%<\/td>\n | 0.103<\/td>\n | 0.0073<\/td>\n<\/tr>\n | \n| a = b \/ c : integers<\/td>\n | + 385%<\/td>\n | 0.154<\/td>\n | 0.0055<\/td>\n<\/tr>\n | \n| a = b \/ c : Numbers<\/td>\n | —<\/td>\n | 0.0317<\/td>\n | 0.0005<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n\n\n| <\/th>\n | Multiplication<\/th>\n | Relative Speed<\/th>\n | Average<\/th>\n | Std. Dev.<\/th>\n<\/tr>\n<\/tbody>\n<\/colgroup>\n\n\n\n\n\n\n<\/colgroup>\n | \n\n| Computer A<\/td>\n | a = int(b * c)<\/td>\n | + 275%<\/td>\n | 0.1477<\/td>\n | 0.0198<\/td>\n<\/tr>\n | \n| a = b * c : integers<\/td>\n | —<\/td>\n | 0.0395<\/td>\n | 0.008<\/td>\n<\/tr>\n | \n| a = b * c : Numbers<\/td>\n | + 12%<\/td>\n | 0.0441<\/td>\n | 0.0151<\/td>\n<\/tr>\n<\/tbody>\n<\/colgroup>\n | \n\n| Computer B<\/td>\n | a = int(b * c)<\/td>\n | + 460%<\/td>\n | 0.1748<\/td>\n | 0.0118<\/td>\n<\/tr>\n | \n| a = b * c : integers<\/td>\n | —<\/td>\n | 0.0312<\/td>\n | 0.0004<\/td>\n<\/tr>\n | \n| a = b * c : Numbers<\/td>\n | + 126%<\/td>\n | 0.0831<\/td>\n | 0.0156<\/td>\n<\/tr>\n<\/tbody>\n<\/colgroup>\n | \n\n| Computer C<\/td>\n | a = int(b * c)<\/td>\n | + 210%<\/td>\n | 0.2915<\/td>\n | 0.0159<\/td>\n<\/tr>\n | \n| a = b * c : integers<\/td>\n | —<\/td>\n | 0.0936<\/td>\n | 0.0005<\/td>\n<\/tr>\n | \n| a = b * c : Numbers<\/td>\n | —<\/td>\n | 0.094<\/td>\n | 0<\/td>\n<\/tr>\n<\/tbody>\n<\/colgroup>\n | \n\n| Computer D<\/td>\n | a = int(b * c)<\/td>\n | + 146%<\/td>\n | 0.0780<\/td>\n | 0<\/td>\n<\/tr>\n | \n| a = b * c : integers<\/td>\n | —<\/td>\n | 0.269<\/td>\n | 0.0090<\/td>\n<\/tr>\n | \n| a = b * c : Numbers<\/td>\n | + 18%<\/td>\n | 0.0317<\/td>\n | 0.0004<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n\n\n| <\/th>\n | Bit Shifting<\/th>\n | Relative Speed<\/th>\n | Average<\/th>\n | Std. Dev.<\/th>\n<\/tr>\n<\/tbody>\n<\/colgroup>\n\n\n\n\n\n\n<\/colgroup>\n | \n\n| Computer A<\/td>\n | a = int(b) << int(c)<\/td>\n | + 645%<\/td>\n | 0.2937<\/td>\n | 0.0308<\/td>\n<\/tr>\n | \n| a = b << c : integers<\/td>\n | —<\/td>\n | 0.0395<\/td>\n | 0.008<\/td>\n<\/tr>\n | \n| a = b << c : Numbers<\/td>\n | + 1,860%<\/td>\n | 0.6954<\/td>\n | 0.0097<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Flash holds to the basic speed hierarchy that bit shifting < addition < multiplication < division; and bit shifting, addition, and multiplication are much closer in speed than I anticipated. Bit shifting expects integers, so its poor results with Number types is expected, these results were consistant across all computers. Computer A performed the worst when using number types for bit shifting; however, even with casting all computers were atleast 5 times (500%) slower with numbers. While it is not as fast as using Number types to begin with, this is also a prime example of how casting can save you some processor time. There is a benchmark example working with arrays that proves casting an object to its current type has essentially no cost.<\/p>\n Addition promotion concerns and Iterator speed, 10,000,000 computations per trial. Run the benchmarks: adding<\/a>, iterating<\/a><\/p>\n \n\n\n| <\/th>\n | Addition Promotion<\/th>\n | Relative Speed<\/th>\n | Average<\/th>\n | Std. Dev.<\/th>\n<\/tr>\n<\/tbody>\n<\/colgroup>\n\n\n\n\n\n\n<\/colgroup>\n | \n\n| Computer A<\/td>\n | All Numbers<\/td>\n | —<\/td>\n | 0.0346<\/td>\n | 0.0062<\/td>\n<\/tr>\n | \n| All Integers<\/td>\n | —<\/td>\n | 0.0358<\/td>\n | 0.0068<\/td>\n<\/tr>\n | \n| Mixed<\/td>\n | + 227%<\/td>\n | 0.1146<\/td>\n | 0.0074<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n\n\n| <\/th>\n | Iterator<\/th>\n | Relative Speed<\/th>\n | Average<\/th>\n | Std. Dev.<\/th>\n<\/tr>\n<\/tbody>\n<\/colgroup>\n\n\n\n\n\n\n<\/colgroup>\n | \n\n| Computer A<\/td>\n | Unsigned Integer<\/td>\n | —<\/td>\n | 0.0331<\/td>\n | 0.0054<\/td>\n<\/tr>\n | \n| Integer<\/td>\n | —<\/td>\n | 0.0321<\/td>\n | 0.0040<\/td>\n<\/tr>\n | \n| Number<\/td>\n | + 260%<\/td>\n | 0.1154<\/td>\n | 0.0078<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Flash does this thing called \u2018promotion\u2019 where if it is unsure of what type to return it will default to the more complex type, this happends when you mix types in opperations, which must include the ++ operator. When Flash is unsure of the type it takes it a while to figure out what it should cast the object to, which is why casting is so important. Results were comparable across all computers, on mixed type addition the percentage increase in time ranged from +200% to +500%, number type iterating ranged from +20% to +260%.<\/p>\n Comparing Unary, Postfix, and Verbose statements, 10,000,000 computations per trial. Run the benchmark: All the ways you can add by 1<\/a><\/p>\n \n\n\n| <\/th>\n | Operation<\/th>\n | Relative Speed<\/th>\n | Average<\/th>\n | Std. Dev.<\/th>\n<\/tr>\n<\/tbody>\n<\/colgroup>\n\n\n\n\n\n\n<\/colgroup>\n | \n\n| Computer A<\/td>\n | ++x<\/td>\n | —<\/td>\n | 0.0363<\/td>\n | 0.0075<\/td>\n<\/tr>\n | \n| x++<\/td>\n | —<\/td>\n | 0.0374<\/td>\n | 0.0078<\/td>\n<\/tr>\n | \n| x = x + 1<\/td>\n | —<\/td>\n | 0.0427<\/td>\n | 0.0071<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n I had a professor that claimed ++x was faster than x++, and he appears to be correct, but not enough to significantly matter.<\/p>\n Lessons Learned:<\/p>\n \n- Never divide unless you absolutely need to.<\/li>\n
- If you are unsure about the type an operation returns, cast.<\/li>\n
- Stick to integer types and postfix for your iterators.<\/li>\n
- Always type your variables, besides being easier to read and debug, it is much faster.<\/li>\n<\/ul>\n
Be sensible, all of these operations are in the 10,000,000 range and are among the fastest operations any language can perform. Addition, multiplication, and bit shifting would probably need 100,000,000 or 1,000,000,000 computations per trial before we would see a sizable speed difference; relatively they are so fast that they just are not worth worrying about. Choosing the right data types and operations will speed up you programs but they live in the subset of the fastest code. Unless you are doing an incredible volume of mathematical operations, your desired target of the slowest running code is something else.<\/p>\n Continue to Data Structure Speed<\/a><\/p>\nThis post is part of a series:
\nIntroduction<\/a>
\nMethodology<\/a>
\nOperation Speed<\/a> <– You are here
\nData Structure Speed<\/a>
\nGraphics Speed<\/a>
\nResults<\/a><\/p>\n | | | | | | |