, Please What you were saying about the 'quick responses' and 'small amount of space' made me go through Michael Abrash's books mentally. (I am like total fan of his works. I worship him - maybe because only his books where available back in those days on assembly, optimization and graphics put together).
I would like to tell you all one of the trick that he had up his sleeve, one that explained where to go for optimization. Consider the following pseudo code (with the relative time taken in the square brackets):
START
TASK A [10]
...
...
TASK B [10]
...
...
TASK C [120]
...
...
TASK D [10]
...
...
LOOP 500 TIMES
...
TASK E [10]
...
TASK F [40]
...
END LOOP
...
(the logic moves on)
Say, the values in the square bracket are time take for the task to be done when written in a 3GL (3rd Generation Language).
Now, if you notice the above code, on the first glance, we would jump at optimizing task C, since it takes way too much time. But according to Michael Abrash, and what I have found myself, optimization should be done for those that are repetitive. In the above example, Task F should be optimized.
Let us look at both the cases.
1. Case 'Task C' reduced to 50%:
Time saved = 120 - (120 x 50%) = 60
2. Case 'Task F' reduced to 50%:
Time saved = 500 x (40 - (40 x 50%)) = 500 x (40 - 20)
= 500 x 20 = 10000
3. Case 'Task F' reduced to 75%:
Time saved = 500 x (40 - (40 x 75%)) = 500 x (40 - 30)
= 500 x 10 = 5000
As can be seen, when both the optimization lead to reduction to 50%, optimizing Task F is better. (Case 1 Vs Case 2)
Even when Task F is reduced to only 75% as opposed to the whooping 50% of Task C, the time saved for Case 3 is way higher than that of Case 1. (Case 1 Vs Case 3).
Now these case are theoretical, but trust me, real-case senarious are a lot closer to this than we think.
Oops! I got carried away.
Hope this not way off track, but what I was making a point is that Assembly when used with right strategy can lead to powerful applications.
