Re^3: How to optimize CPU and Memory usage?

[sundialsvc4]

Obviously, both points-of-view are correct.   You, BrowserUK, are constantly squeezing every ounce of capacity and performance out of a program ... because you quite legitimately need to, and you are obviously quite good at it.   But the opposing point is at the same time equally valid:   that Moore’s Law shows no signs of slowing down.   So, it is simultaneously possible to “make poor engineering decisions” in both directions, because there are two costs here:   the cost of computer hardware, and the cost of computer programmers.   Both points-of-view are true and correct.   It entirely depends on the context ... and the OP so-far said nada about this.   So, we really don’t need to argue about that point, do we?

Addressing the OP’s original question, I would suggest these rules-of-thumb:

1. First, objectively validate that there is a valid business issue here.   Beautiful cars and butt-ugly ones can be seen traveling side-by-side on the highway (and you, of course, are stuck behind the one that’s burning oil ... koff, koff), and both of them will arrive at their destination at the same time, thereby achieving the same business purpose.   If one of them burned twice as much gas getting there, their owners might have no reason at all to care.
2. Second, determine if the problem should be solved with software, or hardware, or both.   Of the two, software is vastly more expensive ... and vastly more vulnerable(!) to negative consequences arising from “any sort of change whatsoever, no matter how well-intentioned.”   Chips are cheap, and getting cheaper all the time.
3. If you make it to point #3, it’s time to determine where it hurts the most.   Which program or program(s), under what conditions (i.e. doing what?).   Where is the most bang for the buck?   Which change is likely to produce the most-maintainable future state?
4. Now ... measure.   Profile the thing.   Do not guess about anything, because you are undoubtedly wrong.
5. Next:   “which one will it be ... speed? ... or space?”   CPU ... or Memory?   You cannot have it both ways.   Ever.
6. “Don’t ‘diddle’ code to make it faster ... find a better algorithm.”   That maxim from The Elements of Programming Style (Kernighan & Plauger) is still true.   To make your program run significantly faster, or to use significantly less memory (pick one), you will have to devise (or find) a better algorithm.   There is, I aver, no other way to do it.
7. Now ... prototype.   Put your pinkie-toe into the water and keep your fourth toe dry.   Set up an expendable test-case to demonstrate that your idea is both correct and useful under real conditions.
8. Now implement your change ... but you’re not done yet!   You have just made major changes to the program.   Now, you must construct test cases to prove that the old and the new versions produce identical results in all cases, and that your expected improvements were in fact realized.