Whenever anyone asks about optimisation, I'm reminded of the quote from Michael A. Jackson
The First Rule of Program Optimisation: Don't do it.
The Second Rule of Program Optimisation (for experts only!): Don't do it yet.
Quote from Wikipedia corrected for British English. *8')
Implicit in the second rule is to profile your code and only spend time optimising things which will make a difference.
When programming in assembly, your father's assertion was correct. But that is much closer to the metal than most people program these days. Today even trying to optimise yourself (without profiling) can result in making your code run slower than if you'd done something the more common way, since the common way is more likely to be optimised by modern JIT compilers.
Even in C you have to be pretty good at optimisation to know more about how to optimise a section of code than the compiler does.
If you aren't familiar with much of what Ulrich Drepper talks about in his excellent paper What Every Programmer Should Know About Memory, then you are probably on a loser even trying to optimise youself. Contrary to the papers title however (which is actually an homage to David Goldberg’s equally fantastic What Every Computer Scientist Should Know About Floating-Point Arithmetic) not having this level of understanding does not necessarily stop you being a good programmer, just a different sort of programmer.
strlen() in PHP
I don't know PHP, so it really isn't obvious what
isset() is meant to do. I can infer it from context, but this means that it will be similarly obscure to novice PHP programmers and might even cause more experienced programmers to double-take. This is the sort of idiomatic use of a language which can make maintenance a nightmare.
Not only that, but there is no guarantee that
isset() will always be more efficient, just because it is more efficient now. An optimisation now might not be an optimisation next year, or in 10 years. CPUs, systems, compilers improve and change over time. If the performance of PHP's
strlen() is a problem, PHP might get modified in the future, then all of the isset() optimisations may need to be removed to optimise the code once more.
Every optimisation has the potential to become a future anti-optimisation, so should be considered a possible code smell, to be kept to a minimum.
An example from personal experience
As an example of such an anti-optimisation, I once had to sanitise a huge codebase filled with code of the form
if x==0 z=0 else z=x*y because someone had made the assumption that a floating point multiply was always going to be more expensive than a branch. On the original target architecture this optimisation made the code run an order of magnitude faster, but times change.
When we tried using this code on a more modern CPU which was highly pipelined the performance was horrifically bad - every one of these statements cause a pipeline flush. Simplifying all of these lines of code to just
z=x*y made the program run an order of magnitude faster on the new architecture, restoring the performance lost by the anti-optimisation.
The problems we typically have to optimise for today are very different to the ones we had to optimise for 20 or even 10 years ago.
Then we worried about doing the most work per clock cycle, now we are more likely to be worrying about pipeline flushes, branch mispredictions and cache misses at the CPU level, but locks and interprocess communication are becoming much more significant as we move to multi-process and multi-processor architectures. Drepper's paper can really help with understanding many of these issues.