There is exactly one question you need to have in mind when optimizing a system in depth: “how can I not do this work at all?”

Using #Rust, #wasm, algorithms with nicer Big O, etc, are distractions compared to the simple fact that O(0) will beat them all.

So when you comb over a system, genuinely ask yourself why you’re doing something and what it would take to not do it at all, and only worry about alternative optimizations when you’ve exhausted all possibilities that involve skipping the work altogether.

This is probably very obvious when I say it like that, but people still neglect, on a regular basis, to do true deep dives into “why at all?” before they start reaching for cure optimizations. Every damn time.

@zkat I always think of GHC optimizing out an entire computation from a benchmark because the result was never printed to the screen.

https://www.reddit.com/r/programming/comments/25aej/why_the_great_language_shootout_changed_because/c25dmg/

Why the Great Language Shootout changed because Haskell was too fast

Posted in r/programming by u/ktr73 • 191 points and 81 comments

reddit
@zkat fast speed make my pp bigger
@js yes, more content for my PowerPoint
@zkat more and more I skip entire projects for this reason 😅😅😬
@zkat This. I recall Andrei Alexandrescu gave a talk about optimization that was pretty much just: "to go fast, do less work."
@zkat No code is faster than no code :)
@zkat "the best work is work we don't have to do" applies in computation and labour
@zkat but is O(0) faster in Rust or WASM? :P

@zkat "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."

Honestly, I was introduced to that via RFC1925, but the original still remains so broadly applicable.

@zkat Sloth is a virtue.

@virtuous_sloth @zkat Laziness, impatience, and hubris.

https://thethreevirtues.com

The Three Virtues of a GREAT Programmer

@virtuous_sloth @zkat

Only when it is "proactive sloth" or "constructive laziness".

@zkat I, uh... Is this apropos of something in particular?

Because it just showed up in my tootstream very shortly after somebody else posted about the GROSS initiative of Hawaii Pacific Health, as documented in a Harvard Business Review case study.

GROSS stands for "Get Rid of Stupid Stuff", and the initiative was about taming the electronic medical records system that they used, by ripping things out of it.

A Simple Solution for Simplifying Work Processes

"Getting Rid of Stupid Stuff" in health care.

Harvard Business Review
@siderea working on orogene and coming up with interesting ways to make it Very Fast
@zkat correct answer
@zkat I remember an interview years ago where I and a colleague were practically begging the candidate for this answer. They finally said, “I’m sorry. I’ve been working on a class project where I designed my own single board computer, and I wrote an OS for it and I was up all night getting it to boot.” Interview complete, offer extended. One of the most amazing perf engineers ever. Wrote an article on “let’s see if we can make this go faster” that was a joy to read. “Oh, that’s better. Now, can we do it again? Why, yes we can!” So much fun. Glad we stuck with trying to get the answer. It was in there, and how!
@zkat I’ve seen folks take this too far, just cutting features that people were using, because they couldn’t be done elegantly in a “cloud-native” architecture.
@zkat those were the motivating factors behind #LMDB - transaction logging sucks, so let's get rid of that. Locking sucks, so let's get rid of that. Caching sucks, so let's get rid of that. https://openldap.org/pub/hyc/mdb-slides.pdf
@zkat in my IT career, whenever I was asked to build a system or add a feature, I always asked "Why do you need this? And what will you do if you don't get it?" Saved a lot of time and work.
@zkat this came up when I was looking at Apples “image capture” program to download 60,000 photos off my wife’s phone. It was demonstrating exponential behavior, and I was trying to figure it out. It turned out that they were re-sorting the entire list after every operation. No matter how fast your sort is, if you’re doing it after every operation you’re going to have a bad time.
@zkat is there a Tao of Programming story like this? I remember the one about the junior programmer with a handheld game and the master programmer “reveals” to the junior a third end state that is neither win or loss (broken).
@zkat two junior programmers approach the master begging him to evaluate their solutions to a problem. One brags that his code is elegant, the other that his is fast. The master programmer deletes both of their source files and says, “We do not need to do that, at all.” The junior programmers were then enlightened.
@zkat This works very well in systems engineering and product development. "How can we not implement this feature at all?" or "How can we document how customers can do this given the features we already have?"
@zkat
And when you delete code, you're (statistically at least) deleting bugs :)