5 ms·

> Premature optimization is not really a thing Okay. I'm going to stop this thread right there and take some opportunity to provide some mentoring. I hope yo

> Premature optimization is not really a thing Okay. I'm going to stop this thread right there and take some opportunity to provide some mentoring. I hope you accept this, as it will help in your career. Read this paper. It is a classic. https://pic.plover.com/knuth-GOTO.pdf https://pic.plover.com/knuth-GOTO.pdf

nikanj 8y ago
Knuth wasn't saying "just ignore performance altogether", he was saying "stop making things needlessly complicated for the last bit of juice".
- nanolith 8y ago
  For instance, pulling in the STL for an interface header instead of encapsulating these details. :-) No one is claiming that we should ignore performance all together. But, understanding through profiling where performance issues are and designing toward a faster implementation is more important than trying to inline definitions up front.
  - Silhouette 8y ago
    Do you also write all your functions to pass large inputs by value until a profiler says you can pass a const reference? Some implementation details are so well understood that you really don't need a profiler to do what is probably the right thing by default.
    - nanolith 8y ago
      > Do you also write all your functions to pass large inputs by value until a profiler says you can pass a const reference? No, but neither do I pass types that fit in a native integer by const reference because copies should be avoided at all costs. There is always a tradeoff. > Some implementation details are so well understood that you really don't need a profiler to do what is probably the right thing by default. Avoiding any and all indirection at all costs is not one of these. The pImpl pattern, much like virtual methods, function pointers, etc., are each tools. Indirection is a trade-off that is either worth the expense in cache misses or is not. The cost is not so cut and dried as others in the thread have assumed.
      - Silhouette 8y ago
        Avoiding any and all indirection at all costs is not one of these. "Any and all"? Perhaps not. However, I believe the context here was standard library headers. Those are full of small, often-used functions, so avoiding idioms based on indirection such as pImpl is about as close to a black and white rule as you're ever going to find in the programming world.
        nanolith 8y ago
        Nowhere did I say that pImpls should only be used. That was only one of several strategies I discussed. The article may have discussed standard headers, but it was neither titled to indicate that it was talking about only standard headers, nor are the problems it discussed localized only to standard headers. My original comment did not limit the discussion to only standard headers.
erubin 8y ago
you may not be aware but your comment came off as somewhat condescending, given that you don't really have any idea where parent poster is coming from or what their background is
- nanolith 8y ago
  If someone says that premature optimization isn't a thing, I don't think it is condescending to point out that it is by posting original source material. :-)
  - shereadsthenews 8y ago
    Well, to the extent that it is a thing it only wastes the programmer’s time. I happen to think programmers are spending too little time, so that doesn’t bother me. Wasting CPU time on the other hand bothers me a lot!
  - cgrealy 8y ago
    > it only wastes the programmer’s time. ... Wasting CPU time on the other hand bothers me a lot! As always the answer is... it depends. Programmer time costs money, CPU time is cheap by comparison. If you're building something that runs occasionally, or is IO/UI/network bound... CPU time is largely irrelevant. But if you're building something that runs in a tight loop or a library that will be compiled in millions of lines of code, then the wasted programmer time will absolutely be worth the ROI.
    - shereadsthenews 8y ago
      Yes, but, again, this article is about standard headers. Since it is impossible for STL library authors to decide that they are or are not writing for a performance-sensitive audience, it behooves them to provide completely visible header-only implementations of everything.
    - kllrnohj 8y ago
      The pImpl pattern costs programmer time as it's more code to write. By contrast compiling is just CPU time and you can trivially throw a bigger workstation at the problem.
CyberDildonics 8y ago
Software still needs to be architected for performance from the start. Trying to micro optimize a loop before you know you need it what Knuth was saying to avoid.
- nanolith 8y ago
  Right. Much like avoiding pImpl because it might make a function call that occurs 0.001% of the time faster. That is the basis of the thread I was replying to. Understanding what you are optimizing FOR and where the most attention should be spent is the crux of Knuth's argument. Trying to be clever up-front is often counter-productive. There is nothing wrong with making some architectural decisions up front, but that is much different than avoiding pImpls at all costs because indirection is slower. Indirection doesn't always matter, and it should only be tackled when and where it does.
  - srean 8y ago
    Well pImpl itself could be a premature optimization.
    - nanolith 8y ago
      Sure, and I would never recommend that indirection be used all the time as that would be premature. However, if compilation times have gotten painful enough that we need to examine performance improvements to our headers, the pImpl pattern is one of many tools in the toolbox. So are forward headers and other compiler firewall techniques.
    - AdieuToLogic 8y ago
      The "pimpl idiom"[0] is about insulation, not optimization. What it affords is ensuring collaborators have no knowledge of a type's implementation details (data as well as private methods), which also has the byproduct of allowing for faster compilation times. HTH 0 - https://cpppatterns.com/patterns/pimpl.html https://cpppatterns.com/patterns/pimpl.html
kllrnohj 8y ago
You should read the paper a bit more closely. "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3 %. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified" We know that cache misses are not a small in-efficiency. This has been measured & observed on many real systems as a real, systemic problem. It's why data-oriented design is currently the King of game engine world, because cache misses kill performance. It is not premature to warn against it as a general practice as a result, as that's systemic de-optimization that will likely impact the critical 3%.
- nanolith 8y ago
  I think you may want to read the quote from the paper a bit more carefully. "...he will be wise to look carefully at the critical code; but only after that code has been identified" I was told that "premature optimization is not really a thing" as a response to a reply I received that pImpls should be avoided at all costs. When we analyze the performance impact of software, we don't shotgun change things because of a generalized fear of cache misses. We examine critical code paths and make changes there based on profile feedback. That is the spirit of what Knuth is saying in this quote. Look carefully at critical code, BUT ONLY AFTER that code has been identified. A cache miss is critical when it is in a critical path. So, we write interfaces with this in mind. Compilation time matters, as does runtime performance. Either way, we identify performance bottlenecks as they come up and we optimize them. Avoiding clearer coding style, such as encapsulation, because it MIGHT create faster code, is counter-productive. We can apply the Pareto Principle to understand that 80% of the performance overhead can be found in 20% of the code. The remaining 80% of the code can use pImpls or could be rewritten in Haskell for all it matters for performance. But, that code still needs to be compiled, and often by clients who only have headers and library files. Subjecting them to long compiles to gain an unimportant improvement in performance in code that only rarely gets called is a bad trade. Spend that time optimizing the parts of the code that matter, which, as Knuth says, should only be done after this code has been identified. EDIT: the downvoting on this comment is amusing, given that "avoid pImpls" is exactly the sort of 97% cruft that Knuth was addressing.
deleted 8y ago
[deleted]

nikanj 8y ago

Knuth wasn't saying "just ignore performance altogether", he was saying "stop making things needlessly complicated for the last bit of juice".

nanolith 8y ago
For instance, pulling in the STL for an interface header instead of encapsulating these details. :-) No one is claiming that we should ignore performance all together. But, understanding through profiling where performance issues are and designing toward a faster implementation is more important than trying to inline definitions up front.
- Silhouette 8y ago
  Do you also write all your functions to pass large inputs by value until a profiler says you can pass a const reference? Some implementation details are so well understood that you really don't need a profiler to do what is probably the right thing by default.
  - nanolith 8y ago
    > Do you also write all your functions to pass large inputs by value until a profiler says you can pass a const reference? No, but neither do I pass types that fit in a native integer by const reference because copies should be avoided at all costs. There is always a tradeoff. > Some implementation details are so well understood that you really don't need a profiler to do what is probably the right thing by default. Avoiding any and all indirection at all costs is not one of these. The pImpl pattern, much like virtual methods, function pointers, etc., are each tools. Indirection is a trade-off that is either worth the expense in cache misses or is not. The cost is not so cut and dried as others in the thread have assumed.
    - Silhouette 8y ago
      Avoiding any and all indirection at all costs is not one of these. "Any and all"? Perhaps not. However, I believe the context here was standard library headers. Those are full of small, often-used functions, so avoiding idioms based on indirection such as pImpl is about as close to a black and white rule as you're ever going to find in the programming world.
      - nanolith 8y ago
        Nowhere did I say that pImpls should only be used. That was only one of several strategies I discussed. The article may have discussed standard headers, but it was neither titled to indicate that it was talking about only standard headers, nor are the problems it discussed localized only to standard headers. My original comment did not limit the discussion to only standard headers.

erubin 8y ago

you may not be aware but your comment came off as somewhat condescending, given that you don't really have any idea where parent poster is coming from or what their background is

nanolith 8y ago
If someone says that premature optimization isn't a thing, I don't think it is condescending to point out that it is by posting original source material. :-)
- shereadsthenews 8y ago
  Well, to the extent that it is a thing it only wastes the programmer’s time. I happen to think programmers are spending too little time, so that doesn’t bother me. Wasting CPU time on the other hand bothers me a lot!
- cgrealy 8y ago
  > it only wastes the programmer’s time. ... Wasting CPU time on the other hand bothers me a lot! As always the answer is... it depends. Programmer time costs money, CPU time is cheap by comparison. If you're building something that runs occasionally, or is IO/UI/network bound... CPU time is largely irrelevant. But if you're building something that runs in a tight loop or a library that will be compiled in millions of lines of code, then the wasted programmer time will absolutely be worth the ROI.
  - shereadsthenews 8y ago
    Yes, but, again, this article is about standard headers. Since it is impossible for STL library authors to decide that they are or are not writing for a performance-sensitive audience, it behooves them to provide completely visible header-only implementations of everything.
  - kllrnohj 8y ago
    The pImpl pattern costs programmer time as it's more code to write. By contrast compiling is just CPU time and you can trivially throw a bigger workstation at the problem.

CyberDildonics 8y ago

Software still needs to be architected for performance from the start. Trying to micro optimize a loop before you know you need it what Knuth was saying to avoid.

nanolith 8y ago
Right. Much like avoiding pImpl because it might make a function call that occurs 0.001% of the time faster. That is the basis of the thread I was replying to. Understanding what you are optimizing FOR and where the most attention should be spent is the crux of Knuth's argument. Trying to be clever up-front is often counter-productive. There is nothing wrong with making some architectural decisions up front, but that is much different than avoiding pImpls at all costs because indirection is slower. Indirection doesn't always matter, and it should only be tackled when and where it does.
- srean 8y ago
  Well pImpl itself could be a premature optimization.
  - nanolith 8y ago
    Sure, and I would never recommend that indirection be used all the time as that would be premature. However, if compilation times have gotten painful enough that we need to examine performance improvements to our headers, the pImpl pattern is one of many tools in the toolbox. So are forward headers and other compiler firewall techniques.
  - AdieuToLogic 8y ago
    The "pimpl idiom"[0] is about insulation, not optimization. What it affords is ensuring collaborators have no knowledge of a type's implementation details (data as well as private methods), which also has the byproduct of allowing for faster compilation times. HTH 0 - https://cpppatterns.com/patterns/pimpl.html https://cpppatterns.com/patterns/pimpl.html

kllrnohj 8y ago

You should read the paper a bit more closely. "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3 %. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified" We know that cache misses are not a small in-efficiency. This has been measured & observed on many real systems as a real, systemic problem. It's why data-oriented design is currently the King of game engine world, because cache misses kill performance. It is not premature to warn against it as a general practice as a result, as that's systemic de-optimization that will likely impact the critical 3%.

nanolith 8y ago
I think you may want to read the quote from the paper a bit more carefully. "...he will be wise to look carefully at the critical code; but only after that code has been identified" I was told that "premature optimization is not really a thing" as a response to a reply I received that pImpls should be avoided at all costs. When we analyze the performance impact of software, we don't shotgun change things because of a generalized fear of cache misses. We examine critical code paths and make changes there based on profile feedback. That is the spirit of what Knuth is saying in this quote. Look carefully at critical code, BUT ONLY AFTER that code has been identified. A cache miss is critical when it is in a critical path. So, we write interfaces with this in mind. Compilation time matters, as does runtime performance. Either way, we identify performance bottlenecks as they come up and we optimize them. Avoiding clearer coding style, such as encapsulation, because it MIGHT create faster code, is counter-productive. We can apply the Pareto Principle to understand that 80% of the performance overhead can be found in 20% of the code. The remaining 80% of the code can use pImpls or could be rewritten in Haskell for all it matters for performance. But, that code still needs to be compiled, and often by clients who only have headers and library files. Subjecting them to long compiles to gain an unimportant improvement in performance in code that only rarely gets called is a bad trade. Spend that time optimizing the parts of the code that matter, which, as Knuth says, should only be done after this code has been identified. EDIT: the downvoting on this comment is amusing, given that "avoid pImpls" is exactly the sort of 97% cruft that Knuth was addressing.

deleted 8y ago

[deleted]