5 ms·

Casey is a bit of a hardcore crusader on the topic, but I'd hardly call dogmatic someone who can provide you evidence and measurements backing their thesis. Th

Casey is a bit of a hardcore crusader on the topic, but I'd hardly call dogmatic someone who can provide you evidence and measurements backing their thesis. The tests he put together here are hardly something I'd call a straw-man argument, they seem like reasonable simplification of real-cases.

st3fan 4y ago
Evidence in a micro benchmark of a single page of code. The focus on performance here ignores the fact that most programs are large systems of many things that interact with each other. That is where good design and abstractions and “clean code” can really help. Like all things it is about finding a balance and applying the right techniques to the right parts of a larger system.
- TheFattestNinja 4y ago
  True, the example is simplistic, but that's just to make it fit within reasonable exposition. The author has in the past shown (elsewhere) how his techniques can actually make dramatic differences in more concrete examples (he rose to some Internet fame for building a performant shell that could actually handle larger outputs orders of magnitude better than most available alternatives). To me the interesting point is the reminder that there is an innate tension between going fast and being "clean" (i.e. maintanable/understandable). And once you are aware of it you can make your decisions in an informed way. Too often this tension is forgotten/ignored/dogmatically put to the back ("performance doesn't matter over cleanliness" and the likes). Mind you, I'm also of the camp that performance is very secondary to cleanliness in modern enterprises, but I appreciate a reminder of just how much we are sacrificing on this altar.
  - cma 4y ago
    It was Windows Terminal he wrote something faster than. Windows terminal was doing a whole GPU draw call per character (at 2x standard terminal height, 160x25, it was as many draw calls as a AAA game).
    - gongle 4y ago
      No matter what design choices you argue for there are always ways to be an idiot about the implementation
    - vkou 4y ago
      Which is an excellent argument for why the WT team should have done some benchmarking, identified that they have a really dumb O(M*N) bottleneck in a critical part of their application (their rendering code), and optimized it. It is not an excellent argument for why 'clean code' is not a better fit for the other 99% of their codebase.
- gjadi 4y ago
  I'd say that it really depends on what the code needs to do. For example, if the code is to be distributed and extended as a third-party library, then the class hierarchy is probably a better fit to allow extensibility. But if the purpose of the API is to compute the area of given shapes (as in the example), then it makes sense to make it efficient and there is no use to provide extensibility to the outside world. The advocates of "clean code" that Casey mentions will go for extensibility no matter the use. I find it very interesting to have numbers to weight what you are leaving when you go the extensibility route instead of the non-pessimistic route.
  - st3fan 4y ago
    > The advocates of "clean code" that Casey mentions will go for extensibility no matter the use. Unfortunately this is just some catchy stereotyping that probably doesn't match reality.
    - gjadi 4y ago
      I don't know. Before reading Casey, I'd say most, if not all, of my APIs would look like the "clean code" style. The process was "think about the model, design a class hierarchy that fits with the model, add the operations". Even if I don't think about extensibility, that's how I thought my code. Why? Because when I think about performance, I used to think about algorithms and I/O optimizations (for example batching). Now I'll look into this data-oriented programming-thing and see how that applies to my platform (embedded Java) :D
    - jstimpfle 4y ago
      The code examples with the abstract / virtual methods for the most straightforward concepts are a clown show. Not cleanliness but madness.
      - loup-vaillant 4y ago
        That's what you get with SOLID. Madness.
      - deleted 4y ago
ajmurmann 4y ago
Unfortunately, everything in our profession is a tradeoff. Faster and maintainable are two of the many quality metrics you can optimize for that will be at odds at times. What the right balance is for a given piece of code depends on so much context. It's a hard balance to get right.
Barrin92 4y ago
> they seem like reasonable simplification of real-cases. Paraphrasing Russ Ackoff, doing the right thing and doing a thing right is the difference between wisdom or effectiveness and efficiency. What Casey is doing here may be efficient, but calculating a billion rectangles doesn't present a realistic or general use case. "Clean Code" or any paradigm of the sort aims to make qualitative, not quantitative improvements to code. What you gain isn't performance but clarity when you build large systems, reduction in errors, reduce complexity, and so on. Nobody denies that you can make a program faster by manually squeezing performance out if it. But that isn't the only thing that matters, even if it's something you can easily benchmark. Looking at a tiny code example tells you very little about the consequences of programming like this. If we program with disregard for the system in favour of performance of one of its parts, what does that mean three years down the line, in a codebase with millions of lines of code?`That's just one question.
vore 4y ago
Performance measurements are only one dimension of code quality. Having a laser focus on it disregards why you would want to sacrifice performance for a different dimension of code quality, such as extensibility for different requirements. You should check if your code is in the hot path before optimizing, because the more you couple things together the harder it is to change it around. For instance, in Casey's example, if you wanted to add a polygon shape but you've optimized calculating area into multiplying height x width by a coefficient, that requires a significant refactor. If you are sure you don't need polygons, that's a perfectly fine optimization. But if you do, you need to start deoptimizing.
lmm 4y ago
These examples are absolutely a strawman. He's imagining there's one specific access pattern that's executed thousands of times per second. In a realistic codebase you're accessing the data less often but in multiple different (often subtly so!) ways. Cache efficiency is everything for modern CPUs, so you can't "simplify" the access patterns without making your benchmarks unrepresentative.
- _dain_ 4y ago
  How is it a strawman when it's literally taken from a Clean Code textbook?
  - lmm 4y ago
    His benchmarks aren't taken from the textbook. If you benchmarked the textbook's changes in a realistic context you'd get quite different results.
- mtrower 4y ago
  What defines a codebase as realistic, exactly? There are many, many programs out there doing various things in various ways.

st3fan 4y ago

Evidence in a micro benchmark of a single page of code. The focus on performance here ignores the fact that most programs are large systems of many things that interact with each other. That is where good design and abstractions and “clean code” can really help. Like all things it is about finding a balance and applying the right techniques to the right parts of a larger system.

TheFattestNinja 4y ago
True, the example is simplistic, but that's just to make it fit within reasonable exposition. The author has in the past shown (elsewhere) how his techniques can actually make dramatic differences in more concrete examples (he rose to some Internet fame for building a performant shell that could actually handle larger outputs orders of magnitude better than most available alternatives). To me the interesting point is the reminder that there is an innate tension between going fast and being "clean" (i.e. maintanable/understandable). And once you are aware of it you can make your decisions in an informed way. Too often this tension is forgotten/ignored/dogmatically put to the back ("performance doesn't matter over cleanliness" and the likes). Mind you, I'm also of the camp that performance is very secondary to cleanliness in modern enterprises, but I appreciate a reminder of just how much we are sacrificing on this altar.
- cma 4y ago
  It was Windows Terminal he wrote something faster than. Windows terminal was doing a whole GPU draw call per character (at 2x standard terminal height, 160x25, it was as many draw calls as a AAA game).
  - gongle 4y ago
    No matter what design choices you argue for there are always ways to be an idiot about the implementation
  - vkou 4y ago
    Which is an excellent argument for why the WT team should have done some benchmarking, identified that they have a really dumb O(M*N) bottleneck in a critical part of their application (their rendering code), and optimized it. It is not an excellent argument for why 'clean code' is not a better fit for the other 99% of their codebase.
gjadi 4y ago
I'd say that it really depends on what the code needs to do. For example, if the code is to be distributed and extended as a third-party library, then the class hierarchy is probably a better fit to allow extensibility. But if the purpose of the API is to compute the area of given shapes (as in the example), then it makes sense to make it efficient and there is no use to provide extensibility to the outside world. The advocates of "clean code" that Casey mentions will go for extensibility no matter the use. I find it very interesting to have numbers to weight what you are leaving when you go the extensibility route instead of the non-pessimistic route.
- st3fan 4y ago
  > The advocates of "clean code" that Casey mentions will go for extensibility no matter the use. Unfortunately this is just some catchy stereotyping that probably doesn't match reality.
  - gjadi 4y ago
    I don't know. Before reading Casey, I'd say most, if not all, of my APIs would look like the "clean code" style. The process was "think about the model, design a class hierarchy that fits with the model, add the operations". Even if I don't think about extensibility, that's how I thought my code. Why? Because when I think about performance, I used to think about algorithms and I/O optimizations (for example batching). Now I'll look into this data-oriented programming-thing and see how that applies to my platform (embedded Java) :D
  - jstimpfle 4y ago
    The code examples with the abstract / virtual methods for the most straightforward concepts are a clown show. Not cleanliness but madness.
    - loup-vaillant 4y ago
      That's what you get with SOLID. Madness.
    - deleted 4y ago

ajmurmann 4y ago

Unfortunately, everything in our profession is a tradeoff. Faster and maintainable are two of the many quality metrics you can optimize for that will be at odds at times. What the right balance is for a given piece of code depends on so much context. It's a hard balance to get right.

Barrin92 4y ago

> they seem like reasonable simplification of real-cases. Paraphrasing Russ Ackoff, doing the right thing and doing a thing right is the difference between wisdom or effectiveness and efficiency. What Casey is doing here may be efficient, but calculating a billion rectangles doesn't present a realistic or general use case. "Clean Code" or any paradigm of the sort aims to make qualitative, not quantitative improvements to code. What you gain isn't performance but clarity when you build large systems, reduction in errors, reduce complexity, and so on. Nobody denies that you can make a program faster by manually squeezing performance out if it. But that isn't the only thing that matters, even if it's something you can easily benchmark. Looking at a tiny code example tells you very little about the consequences of programming like this. If we program with disregard for the system in favour of performance of one of its parts, what does that mean three years down the line, in a codebase with millions of lines of code?`That's just one question.

vore 4y ago

Performance measurements are only one dimension of code quality. Having a laser focus on it disregards why you would want to sacrifice performance for a different dimension of code quality, such as extensibility for different requirements. You should check if your code is in the hot path before optimizing, because the more you couple things together the harder it is to change it around. For instance, in Casey's example, if you wanted to add a polygon shape but you've optimized calculating area into multiplying height x width by a coefficient, that requires a significant refactor. If you are sure you don't need polygons, that's a perfectly fine optimization. But if you do, you need to start deoptimizing.

lmm 4y ago

These examples are absolutely a strawman. He's imagining there's one specific access pattern that's executed thousands of times per second. In a realistic codebase you're accessing the data less often but in multiple different (often subtly so!) ways. Cache efficiency is everything for modern CPUs, so you can't "simplify" the access patterns without making your benchmarks unrepresentative.

_dain_ 4y ago
How is it a strawman when it's literally taken from a Clean Code textbook?
- lmm 4y ago
  His benchmarks aren't taken from the textbook. If you benchmarked the textbook's changes in a realistic context you'd get quite different results.
mtrower 4y ago
What defines a codebase as realistic, exactly? There are many, many programs out there doing various things in various ways.