Return to Answer

Three quotes to sumarize good practices regarding optimizations:

• Premature optimization is the root of all evil
  Donald Knuth
• Don't diddle code, find better algorithms
  Kernighan&Plauger
• Debugging is twice as hard as writing the code. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
  B.W.Kernighan

The rest is myth.

Some less important comments about your examples:

• Not breaking down a 1000 lines a thousand line function to avoid a couple of function calls, puts the performance focus on 0,1% of the instructions: 99,1% of probability that performance issues are elsewhere IMHO.
• Anyway, isn't it somewhat obsolete in a time of global optimizers and inlining? Does anyone remember the keyword register that was the summum of hand-crafted optimizations 30 years ago  ?
• No SRP to avoid object overhead could be valid but only in case of a misunderstanding of SRP. SRP is according to Uncle Bob -- the inventor of the concept -- about (human) reasons to change, not about multiplying classes for decreasing the number of functions (which to the extreme would make OOP a variant of procedural programming). The benefits of real SRP far outweighs its drawbacks IMHO.
• ++i; , i++; and i=i+1 taken isolated generate exactly the same code with a decently optimizing compiler. So ++i is no longer an optimization! But it's still valid from the point of view of expressivity. But this is a question of style: you like it or not. If not, maybe C**++** is not the most suitable language for you ;-)
• Many other human micro-optimizations are nowadays outperformed by the optimizer, which can take advantage of deep knowledge of the target CPU and analyse in-depth several alternatives. But finding better algorithm is still for us. I hope that we will outperform AI in this area for a long time (although some day I wonder).

Three quotes to sumarize good practices regarding optimizations:

• Premature optimization is the root of all evil
  Donald Knuth
• Don't diddle code, find better algorithms
  Kernighan&Plauger
• Debugging is twice as hard as writing the code. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
  B.W.Kernighan

The rest is myth.

Some less important comments about your examples:

• Not breaking down a thousand line function to avoid a couple of function calls puts the performance focus on 0.1% of the instructions: 99.1% of probability that performance issues are elsewhere IMHO.
• Anyway, isn't it somewhat obsolete in a time of global optimizers and inlining? Does anyone remember the keyword register that was the summum of hand-crafted optimizations 30 years ago?
• No SRP to avoid object overhead could be valid but only in case of a misunderstanding of SRP. SRP is according to Uncle Bob -- the inventor of the concept -- about (human) reasons to change, not about multiplying classes for decreasing the number of functions (which to the extreme would make OOP a variant of procedural programming). The benefits of real SRP far outweighs its drawbacks IMHO.
• ++i; , i++; and i=i+1 taken isolated generate exactly the same code with a decently optimizing compiler. So ++i is no longer an optimization! But it's still valid from the point of view of expressivity. But this is a question of style: you like it or not. If not, maybe C++ is not the most suitable language for you ;-)
• Many other human micro-optimizations are nowadays outperformed by the optimizer, which can take advantage of deep knowledge of the target CPU and analyse in-depth several alternatives. But finding better algorithm is still for us. I hope that we will outperform AI in this area for a long time (although some day I wonder).

Three quotes to sumarize good practices regarding optimizations:

• Premature optimization is the root of all evil
  Donald Knuth
• Don't diddle code, find better algorithms
  Kernighan&Plauger
• Debugging is twice as hard as writing the code. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
  B.W.Kernighan

The rest is myth.

Some less important comments about your examples:

• Not breaking down a 1000 lines a thousand line function to avoid a couple of function calls, puts the performance focus on 0,1% of the instructions: 99,1% of probability that performance issues are elsewhere IMHO.
• Anyway, isn't it somewhat obsolete in a time of global optimizers and inlining? Does anyone remember the keyword register that was the summum of hand-crafted optimizations 30 years ago ?
• No SRP to avoid object overhead could be valid but only in case of a misunderstanding of SRP. SRP is according to Uncle Bob -- the inventor of the concept -- about (human) reasons to change, not about multiplying classes for decreasing the number of functions (which to the extreme would make OOP a variant of procedural programming). The benefits of real SRP far outweighs its drawbacks IMHO.
• ++i; / i++; and i=i+1 generates exactly the same code with a decently optimizing compiler. It's no longer an optimization! But it's still valid from the point of view of expressivity. But this is a question of style: you like it or not. If not, maybe C**++** is not the most suitable language for you ;-)
• Many other human micro-optimizations are nowadays outperformed by the optimizer, which can take advantage of deep knowledge of the target CPU and analyse in-depth several alternatives. But finding better algorithm is still for us. I hope that we will outperform AI in this area for a long time (although some day I wonder).

Three quotes to sumarize good practices regarding optimizations:

• Premature optimization is the root of all evil
  Donald Knuth
• Don't diddle code, find better algorithms
  Kernighan&Plauger
• Debugging is twice as hard as writing the code. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
  B.W.Kernighan

The rest is myth.

Some less important comments about your examples:

• Not breaking down a 1000 lines a thousand line function to avoid a couple of function calls, puts the performance focus on 0,1% of the instructions: 99,1% of probability that performance issues are elsewhere IMHO.
• Anyway, isn't it somewhat obsolete in a time of global optimizers and inlining? Does anyone remember the keyword register that was the summum of hand-crafted optimizations 30 years ago ?
• No SRP to avoid object overhead could be valid but only in case of a misunderstanding of SRP. SRP is according to Uncle Bob -- the inventor of the concept -- about (human) reasons to change, not about multiplying classes for decreasing the number of functions (which to the extreme would make OOP a variant of procedural programming). The benefits of real SRP far outweighs its drawbacks IMHO.
• ++i; , i++; and i=i+1 taken isolated generate exactly the same code with a decently optimizing compiler. So ++i is no longer an optimization! But it's still valid from the point of view of expressivity. But this is a question of style: you like it or not. If not, maybe C**++** is not the most suitable language for you ;-)
• Many other human micro-optimizations are nowadays outperformed by the optimizer, which can take advantage of deep knowledge of the target CPU and analyse in-depth several alternatives. But finding better algorithm is still for us. I hope that we will outperform AI in this area for a long time (although some day I wonder).

Three quotes to sumarize good practices regarding optimizations:

• Premature optimization is the root of all evil
  Donald Knuth
• Don't diddle code, find better algorithms
  Kernighan&Plauger
• Debugging is twice as hard as writing the code. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
  B.W.Kernighan

The rest is myth.

Some less important comments about your examples:

• Not breaking down a 1000 lines a thousand line function to avoid a couple of function calls, puts the performance focus on 0,1% of the instructions: 99,1% of probability that performance issues are elsewhere IMHO.
• Anyway, isn't it somewhat obsolete in a time of global optimizers and inlining? Does anyone remember the keyword register that was the summum of hand-crafted optimizations 30 years ago ?
• No SRP to avoid object overhead could be valid but only in case of a misunderstanding of SRP. SRP is according to Uncle Bob -- the inventor of the concept -- about (human) reasons to change, not about multiplying classes for decreasing the number of functions (which to the extreme would make OOP a variant of procedural programming). THe benefits of real SRP far outweighs its drawbacks IMHO.
• i++ and i++ and i=i+1 generates exactly the same code with a decently optimizing compiler. It's no longer an optimization! But it's still valid from the point of view of expressivity. But this is a question of style: you like it or not. If not, maybe C**++** is not the most suitable language for you ;-)
• Many other human micro-optimizations are nowadays outperformed by the optimizer, which can take advantage of deep knowledge of the target CPU and analyse in-depth several alternatives. But finding better algorithm is still for us. I hope that we will outperform AI in this area for a long time (although some day I wonder).

Three quotes to sumarize good practices regarding optimizations:

• Premature optimization is the root of all evil
  Donald Knuth
• Don't diddle code, find better algorithms
  Kernighan&Plauger
• Debugging is twice as hard as writing the code. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
  B.W.Kernighan

The rest is myth.

Some less important comments about your examples:

• Not breaking down a 1000 lines a thousand line function to avoid a couple of function calls, puts the performance focus on 0,1% of the instructions: 99,1% of probability that performance issues are elsewhere IMHO.
• Anyway, isn't it somewhat obsolete in a time of global optimizers and inlining? Does anyone remember the keyword register that was the summum of hand-crafted optimizations 30 years ago ?
• No SRP to avoid object overhead could be valid but only in case of a misunderstanding of SRP. SRP is according to Uncle Bob -- the inventor of the concept -- about (human) reasons to change, not about multiplying classes for decreasing the number of functions (which to the extreme would make OOP a variant of procedural programming). The benefits of real SRP far outweighs its drawbacks IMHO.
• ++i; / i++; and i=i+1 generates exactly the same code with a decently optimizing compiler. It's no longer an optimization! But it's still valid from the point of view of expressivity. But this is a question of style: you like it or not. If not, maybe C**++** is not the most suitable language for you ;-)
• Many other human micro-optimizations are nowadays outperformed by the optimizer, which can take advantage of deep knowledge of the target CPU and analyse in-depth several alternatives. But finding better algorithm is still for us. I hope that we will outperform AI in this area for a long time (although some day I wonder).