Sometimes I hesitate between “More code to avoid unnecessary operations” and “less code but with redundant operations”. Let me just take an example (Win32 API):
I try to paint some controls manually when the cursor is over it. If the cursor is over this control and it is painted, then it doesn’t need to be painted again before the cursor goes out from it.
Of course, I can just paint this control whenever a WM_MOUSEMOVE appears. Or, I can use more variables to record the state of this control and paint it only when the state is changed.
Although it is not a question (in practice) in my example, I still want to have a feeling for which is the better choice, in general. And if this depends on cases, any way to develop a good sense to do the choice?
(I am not focus on “efficient”. It is more or less like a question as: If you are an idealist of programming, which one is better in your opinion.)
1
There is no better choice in general. Code readability and system performance are two valid goals, and if they are at odds, you must know about the strengths of those two forces in your particular situation before deciding. To say, “when readability and performance are at odds, always choose performance (or readibility)” would be a terrible oversimplification that leads to terrible decisions when followed blindly.
To make good decision, you would consider these forces in the context of your actual requirements. For example:
- UI behaviour, particularly something to do with painting the mouse pointer, is rather sensitive to speed. It may not affect the actual throughput of an application much or at all, but the impression of speed is vital for a good user experience: milliseconds of feedback delay can contribute to subconscious dislike of a system. (Consult user experience professionals for more precise figures, but they are shockingly small.) So in this case, performance may actually be comparatively important rather than a “nice to have”.
- At the same time, graphics rendering code is a rather fundamental part of a large system. You definitely want it to be correct and rock-solid – mis-drawing something in your user interface can leave an even worse impression than feedback lag. This puts a premium on maintainability, and that means readability is also important.
- But rendering sprites, icons or whatever your low-level primitives are is (I hope) a relatively small, contained problem. Once you’ve implemented it, it may not require continuous improvement the way that business rules or interfaces do (how often does a new input modality come long that challenges the established keyboards and mice?), so maybe you can get away with optimizing the hell out off your code and then putting a lid on it. That would mean more opportunity to optimize and less danger of having to unravel your clever tricks again the next time you need to change low-level behavior.
This is not to say that you should optimize for speed, either in this case or in general, just because I named two pro-speed items and one pro-maintenance item. These are just examples of the kind of questions you need to ask to make the right decision depending on the circumstances. Also, you need to quantify the effects you are comparing, e.g. via usability testing and profiling metrics. One big minus can be enough to cancel out the advantages of a whole bunch of small plusses.
0