Optimizing an old assembly code

[AndyPro720]

I have been revising the part one of the course after around 6 months, while I begin to start the second part. What was supposed to be a ten minute glance at the general code, turned out to be a session of few hours where I try and optimize the screen fill assembly code.

I know the purpose of that wasn't to capture the efficiency but rather understanding. Now that we're past that I think it's a fun(frustrating at end) exercise to see the optimizations we can create. I did manage atleast a difference of ~2 seconds from my old code. Of course I did need to run the animation on slow to *see* a noticeable difference.

Anyways, have a look and let me know what you guys think. Would love to rack your memory and gain some suggestions!

https://gist.github.com/AndyPro720/3b02c12025dea3701655c08528d2f2aa

[WBahn]

I agree that it's both fun and frustrating -- and a great learning experience -- to try to improve legacy code.

The fill problem is surprisingly fertile ground for this. First off, there's the question of just what the goal is -- to make it as fast as possible? To make it as short as possible? To make it as "nice" as possible? As is very often the case, these are generally mutually-exclusive goals and different things can be learned by trying to focus on each in turn.

On the "nice" side of things, that comes down to defining how you would like the program to behave and then figuring out how to write a program that behaves that way. The behavior of the fill program in the project is intentionally left very ill-defined -- it merely requires that if you hold the key down long enough the screen eventually becomes becomes all black while if no key is pressed long enough the screen eventually becomes all white. One thing that is very unsatisfying with many (perfectly valid) solutions to this problem is that nothing seems to happen when the person first presses or first releases the key -- it continues either blackening or clearing the screen as if it is ignoring your action (which is exactly what is happening).

So the obvious tweak to the specification is that the program immediately begins filling the screen, starting at the cursor's current location, when a key is pressed and immediately begins clearing the screen, again starting at the cursor's current location, when the key is released. Accomplishing this is surprisingly easy -- but a lot of brain cells tend to get damaged (or at least fatigued from excessive use) along the way. But once you figure out how to do it, you have really added a powerful software design technique to your toolbox.

A couple of other useful changes are to make the screen fill from left to right such that the entire first column of pixels are changed before any in the second column, and so forth. First, do it so that a "column" is actually sixteen pixels wide, then make each column truly one pixel wide. This will not only give some practice in designing a program to achieve a specific goal, but also drive home the point that fast, efficient programs are intrinsically linked to the hardware architecture.

That helps you define software requirements with performance considerations in mind -- and puts you in a position to guide your customers along that same path. Many people will blindly do what the customer says they want, when in reality the customer seldom has a firm grasp on what they really truly need. So if you can point out the pros and cons of what they say they want and a few alternatives, it often results in a much better product specification and a much happier customer in the end.

[AndyPro720]

This was a great read and I do agree that defining a goal before the actual implementation is a much more clean and focused way to go about it. (although, rambling a few brain cells every now and then is the only sane way xD)

And though I am still a student, this part:  

 Many people will blindly do what the customer says they want, when in reality the customer seldom has a firm grasp on what they really truly need. So if you can point out the pros and cons of what they say they want and a few alternatives, it often results in a much better product specification and a much happier customer in the end.

is the true definition of what differentiates a mere engineer from a creator, for me!

I do have a few personal questions, more guidance as a student per se, so if you're comfortable, I'd love to get in touch with you.

Thanks!