Molly Rocket
3 HN recommenders · recommended in 10 months, 2023–2026
22:41 · 1.2M views · Feb 28, 2023
Casey Muratori shows how typical 'clean code' object-oriented patterns can cost large factors in performance. He benchmarks them against simpler data-oriented code.
A frequent citation in debates about SOLID and Clean Code, representing the performance-first side of the argument.
11 comments from Hacker News
The issue with those books is that they don't have any concrete data that affirms that they are worth following. And, in fact, that style of code is largely to blame for why modern software feels so sluggish. They often reduce performance by 10x if not 100x or worse. I like this video on the topic for reasons not to follow SOLID principles[0]. Muratori also has an excellent talk on writing APIs that are flexible and performant[1]. As for books on understanding the hardware performance, Computer Systems: a Programmer's Perspective, is the best example (not the international edition though, according to the author's recommendation). I'm not aware of any architecture books recommended by anyone that cares about performance unfortunately. Most high performance software is written iteratively, meaning they aren't assuming a code structure from the start. Andreas Fredriksson, a lead engine programmer at Insomniac Games, has an excellent quote on how he writes high performance software[2]: > Work backwards from hard constraints and requirements to guide your design. Don’t fall into the trap of designing from a fluffy API frontend before you’ve worked out how the thing will handle a worst case. Don’t be afraid to sketch stuff in while you’re proving out the approach. > The value is what you learn, never the code. Hack it and then delete the code and implement “clean” or whatever you need. But never start there, it gets in the way of real engineering. > As an industry we spend million
> What resources do you recommend folks at my level look into? I'd argue that your best bet for learning is starting a project that drives you, then throwing that project away and starting it over again but try to make the code simpler. This way you can hone into what abstraction is actually necessary to solve your problem. I strongly recommend ignoring design patterns and instead honing in on what the essential data flow is in your problem space. Most design patterns will bloat your code base and, thus, slow both your program and your programming velocity down. As far as programming design and architecture goes, the best talks I have found come out of data orientated design talks. Casey Muratori has a number of talks well worth listening to[0][1][2]. I also enjoy Andrew Kelley's talk on Data Orientated Design specifically as it demonstrates DOD's power with actual numbers to back it up[3]. Tangent: I did my time with OOP design + trying to make my code 'clean' according to popular recommendations you'll see online. All of that time, I consider wasted because I focused too much on what the 'right' abstraction to use was, instead of solving my problem in the simplest way possible. I find now that often the best solution is the one that uses the least amount of abstraction and indirection. (E.g. One big function can be a lot easier to maintain than multiple little functions, you just have to develop a taste for when a function should be split up and why). (If you must have a pa
Look at Casey Murrey's Clean Code horrible performance youtube video: this video I also watched clean code videos and used it in practice, and why it _felt_ right my code size blew up and actually it got harder to understand by other people instead of easier. Nowdays my main guidelines are getting a balance between less lines of code (while still readable), readable variable names and better performance. Also I may get hate here for it, but I learned a lot from watching George Hotz programming tinygrad (available on YouTube).
If you want something real, look at Clean Code Horrible Performance youtube video if you haven't. I also found Bob Martin entertaining, but after trying to follow his suggestions I just got into the trap that Casey Muratori shows: even if I don't care about the performance of the code at the start, the amount of abstractions Uncle Bob advises makes it just too easy to make the code extremely hard to optimize later. this video
You may enjoy “"Clean" Code, Horrible Performance”, from Casey Muratori. this video Casey specialises in game engine research and development [LINK] And has an ongoing course on computer performance for programmers. [LINK]