The Bullshit that is "What Every Programmer Should Know About Memory"

Image via Wikipedia

Ulrich Drepper: What Every Programmer Should Know About Memory

This is bullshit. 114 pages! A revision history!

Obviously this is hardly "What Every Programmer Should Know About Memory". This is one guy's "Everything I Can Say about Memory In One Place without Contradicting Myself".

This is the usual "lambda-the-ultimate" "The Society for the Prevention of Programing" circle-jerk.

Fucktards...

For the sake of argument, lets say you refuse to play the "premature optimization" game. For the sake of argument, lets say you are satisfied with the length of your dick.

How do you in fact make programs with good performance?

(Step 1) Straight-forward & correct implementation

(Step 2) Timing tests and timing profiles under real-world loads. (Don't fool yourself, the best you can do is approach reality with profiling - you can never achieve perfect real-world profiling.)

(Step 3) Under Revision Control, hit the place in your code where you sense you will get the biggest bang for your buck

Repeat Steps 2 & 3 until you sense futility, until you sense rapidly diminishing returns.

(Step 4) Roll back some of the improvements! I am not kidding, you have to give back some of your hard won performance. You need to find a balance between Performance (Latency, Throughput, and Resource Use) and:

• Readability
• Maintainability
• Portability
• Testability
• Ease of Understanding
• Predictability/Stability
• Fewest Lines of Code
• and Validity is merely the "ticket of admission" - without that, nothing counts for shit.

You won't know what Performance you have to give back, until after you implement it and time and profile it. Sorry, that is the way it works. If your coding is so laborious that you cannot bare to think of throwing away even a single line of code, then the Universe is trying to tell you to stop. Programming is Hard, Let's Go Shopping!

(Step 5) Now that you have Performance, add at least one test of the Performance to your automated testing suite. Or else you will give it all back, and then some, with a single ill-advised change to your code in the future. If you don't care enough to Test It, then you don't really care, Period.

(Step 10000) As you write more code, your instincts improve. Your first 100,000 lines of code will be of poor quality, and your next 100,000 will be slightly better. You have to pay your dues, because nobody else is exploring your exact problem domain. You have to find your own road.

Image via Wikipedia

Any other approach is just sucking your own cock through a soda straw. While other people are getting results, you are still playing with yourself.