Why some programs are slower than others?

Tony Kerr, Reporter

Every form of technology we use runs programs. Sometimes there are more than one like with modern computers, but microwaves and other accessories follow just one main program. These programs are normally written by very smart computer programmers. However, we are not always fortunate to have all the programs we need and use be professionally made. A lot of times shortcuts are taken to reduce development time, whether it be sacrificing program memory efficiency, accuracy to what is expected, speed of functions, or even all of these.

Memory efficiency describes how much memory is required to use a program and to some extent the algorithms used in the program. There are normally multiple ways of getting an expected outcome by following different algorithms. For example, trying to calculate every number in a range 1-N, you could add every number 1-N (1+2+3+…+N), or take a much faster approach with N**2/2+(N/2). Given N equals 100,000,000, the desired output would be 5,000,000,050,000,000. This not only saves computational time but also memory and bandwidth, because you would end up storing each of those numbers at some point with the much slower method even if it was just one at a time. Calculating with the slower method a program would use N number of add operations. Whereas the faster method would only use one square operation, two divisions, and one addition. So for the example 100,000,000 operations vs 4 operations. In Python the time difference is perceivable, the fast method taking less than 0.0000005 seconds, while the slow method took over 6.5 seconds.

Accuracy is another place where some programmers will cut corners though it is much easier to detect due to the nature of the issue. This is why unit tests are written to verify that a particular program is able to pass all expected criteria of how it should behave given certain inputs. A decent example of this would be a calculator that is only able to calculate whole number operations and can only return whole numbers. So given 3/2 the answer would return 1, whereas the correct answer is actually 1.5. This would save on programmer time, but much more so on hardware engineering time, however, at the very obvious cost of accuracy.

To combat this lack of accuracy, speed of a function may be given up. Perhaps with many different if statement checks that could be much easier to solve just by processing the data correctly in the first place. Not to say that if statements aren’t needed as they are very important, but sometimes they are overused. Another way speed of a function could be bottle-necked is with cloud computing. Normally, cloud computing is used to perform very demanding tasks quickly, which it does well, but for tasks the computer can do natively much faster than sending a message halfway across the country, this becomes pointless… but some companies like the idea of paid APIs and guarded “black box” functions.