From 6641c52252b9e507bc269e9a17aaa5fd20cac47e Mon Sep 17 00:00:00 2001 From: jtn7 Date: Tue, 7 May 2019 08:50:00 -0400 Subject: [PATCH] Some quote fixes --- performance.md | 26 ++++++++++++++++---------- 1 file changed, 16 insertions(+), 10 deletions(-) diff --git a/performance.md b/performance.md index 65f0e85..6926c35 100644 --- a/performance.md +++ b/performance.md @@ -59,21 +59,25 @@ slider between "Fast Software" and "Fast Deployment" People hear and mindlessly repeat "premature optimization is the root of all evil", but they miss the full context of the quote. -"Programmers waste enormous amounts of time thinking about, or worrying about, +> "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. 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%." -- Knuth +should not pass up our opportunities in that critical 3%." +> +> -- Knuth Add: https://www.youtube.com/watch?time_continue=429&v=RT46MpK39rQ * don't ignore the easy optimizations * more knowledge of algorithms and data structures makes more optimizations "easy" or "obvious" -"Should you optimize? "Yes, but only if the problem is important, the program +Should you optimize? +> Yes, but only if the problem is important, the program is genuinely too slow, and there is some expectation that it can be made faster while maintaining correctness, robustness, and clarity." --- The Practice of Programming, Kernighan and Pike +> +> -- The Practice of Programming, Kernighan and Pike Premature optimization can also hurt you by tying you into certain decisions. The optimized code can be harder to modify if requirements change and harder to @@ -180,12 +184,14 @@ will give a skewed view of where the bottlenecks will be in the finished system. TODO: How to avoid/detect "Death by 1000 cuts" from poorly written software. Solution: "Premature pessimization is the root of all evil". This matches with -my Rule 1: Be deliberate. You don't need to write every line of code +my Rule 1: Be deliberate. You don't need to write every line of code to be fast, but neither should by default do wasteful things. -"Premature pessimization is when you write code that is slower than it needs to +> "Premature pessimization is when you write code that is slower than it needs to be, usually by asking for unnecessary extra work, when equivalently complex code -would be faster and should just naturally flow out of your fingers." -- Herb Sutter +would be faster and should just naturally flow out of your fingers." +> +> -- Herb Sutter Benchmarking as part of CI is hard due to noisy neighbours and even different CI boxes if it's just you. Hard to gate on performance metrics. A good middle @@ -551,7 +557,7 @@ with a good algorithm. We will talk about this in the hardware-specific section. > The fight may not always go to the strongest, nor the race to the fastest, -> but that's the way to bet. +but that's the way to bet. > -- Rudyard Kipling Sometimes the best algorithm for a particular problem is not a single @@ -1018,7 +1024,7 @@ Popular replacements for standard library packages: ## cgo > cgo is not go -> -- Rob Pike +> -- Rob Pike * Performance characteristics of cgo calls * Tricks to reduce the costs: batching @@ -1201,7 +1207,7 @@ faster. > The fastest algorithm can frequently be replaced by one that is almost as fast and much easier to understand. > -> Douglas W. Jones, University of Iowa +> -- Douglas W. Jones, University of Iowa The added complexity has to be enough that the payoff is actually worth it. Another example is cache eviction algorithms. Different algorithms can have