
"Clean" Code, Horrible Performance
About this video
Casey Muratori shows how typical 'clean code' object-oriented patterns can cost large factors in performance. He benchmarks them against simpler data-oriented code.
Why it appears in the archive
A frequent citation in debates about SOLID and Clean Code, representing the performance-first side of the argument.
AI-generated summary and labels from the source dataset; verify important details against the video. Source & credits.
From the Hacker News discussion
> 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
Read original comment ↗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
Read original comment ↗Look at Casey Murrey's Clean Code horrible performance youtube video: [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).
Read original comment ↗You may enjoy “"Clean" Code, Horrible Performance”, from Casey Muratori. [VIDEO] Casey specialises in game engine research and development [LINK] And has an ongoing course on computer performance for programmers. [LINK]
Read original comment ↗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. [VIDEO]
Read original comment ↗1. Single-thread performance This is hardly related to HPC. The closest thing maybe code optimization and competitive programming. First learn how to do anything fast in single process, then think about scale it up later. 2. Parallel programming Learn MPI. Specifically mpi4py. Once you go MPI, you never use python's multiprocessing module (it sucks). But stuffs are mostly about solving linear algebra problems, which I am not that interested in. 4. Distributed Computing Related to MPI. But nowaday distributed GPU computing become a thing, thing that I can think of is Dask. Don't know how to use that. [LINK] 5. Quantum Computing Completely unrelated to HPC, at least in the near future (10 to 30 years). Areas that is the most active in this field is molecular computation. If you don't have a phy/chem PHD, you are not able to read anything beyond college level stuff in this field. And those are only basics stuff like elementary schools' arithmetics. But write your own program to solve those quantum problems in classical computers is interesting, because people there only think about problems that cause scaling issue, not the others. That's why some may think that quantum computer is a replacement of supercomputers. If you can find ways and invent techniques that can reduce timecomplexity in terms of classical algorithm, you are welcome. And literally there is a lot of room for anyone because every quantum computer emulator is unoptimized and slow as hell. Google, Microsoft, IBM,
Read original comment ↗Thanks for the thoughtful reply. > Well it's hard to argue about that tradeoff in general, but I think the existence of languages like Python, Ruby and PHP is compelling. Though I'd accept the argument that they help optimise for neither performance nor changeability! I see the point you're making, and I don't disagree with it. But I should be a bit more clear in what I really meant in my parent comment: Given whatever language a developer is working in, whether it is fast like C++ or a slow language like Python (or perhaps even Minecraft Redstone), I think the programmer that takes a data oriented approach (meaning they write their code thinking about the kinds of data the program can receive and the kind it will likely receive, along with what operations will be the most expensive) will have better code than a programmer that makes a nice object model following all the SOLID principles. The majority of the OOP code I've worked with spends too much time caring about abstractions and encapsulation that performance is lost and the code is no better to work with. > Regarding the DOD/OOP wars, I really love this article, which argues that OOP doesn't have to be bad[1]. I also think that when performance is a requirement, you just have to get more particular about your use of OOP. For example, the difference between Mesh and InstancedMesh[2] in THREE.js. Both are OOP, but have very different performance implications. Absolutely agree here. Classic gamedev.net article. ECS != DOD
Read original comment ↗See for example this playlist of videos of his with some videos from 2021 where he implements a terminal emulator. As he says himself, this project is not so much about terminals as it is about software development practices in general. [LINK] See also this video of his: “Clean” Code, Horrible Performance [VIDEO]
Read original comment ↗