Hello, Jan. Thanks for inviting me to the party!

Of course I agree that it always makes sense to do the best job possible, and (as you know) I have spent many hours playing around with little snippets like you are talking about, trying to shave off a cycle here or a byte there. That sort of thing can be very educational and a lot of fun.

However, when working on a real project, for a real employer who's paying me real money, I think it's important to recognize that "best" doesn't necessarily mean "smallest" or "fastest". You said it yourself:


It's easy to focus on easily-measured variables like code size and execution speed. However, there are also less tangible things to consider, such as maintainability, portability, reliability, and cost. The first trick is to learn to balance all of the variables. Then when you have that figured out, try to realize that the importance of each one of the variables varies from project to project and situation to situation.

Sometimes it will make sense to make the code fast instead of making it small. Sometimes it won't.

Sometimes it will make sense to use ASM instead of C. Sometimes it won't.

Sometimes it will make sense to add hardware instead of adding complexity to the software. Sometimes it won't.

Sometimes it will make sense to spend an hour making a function two cycles faster instead of going home to play ball with your kid. Sometimes it won't.

-- Russ