4 ms·

I write clean code with lots of encapsulation. Not C++ just an ecomm webapp but our business hinges heavily on time to load and we do great there. Clean code o

I write clean code with lots of encapsulation. Not C++ just an ecomm webapp but our business hinges heavily on time to load and we do great there. Clean code or messy code the thing that all fast code has in common - including your example is this: YOU FOCUSED ON IT. You measured it, then improved against the benchmark. You spent time and effort on it so it improved. That's it. That's the secret.

jodrellblank 21d ago
I object on a few fronts. One is that the rewrite has 'mechanical sympathy' with the machine e.g. arrays without pointer chasing can fit more data in CPU cache with fewer stalls while it reads over the main memory bus and waits after every item. That should not be a surprise, it's knowable in advance. Why deliberately ignore knowledge about the machine when designing the code, then come back and use that knowledge? Another objection is to the idea of "measure then improve". Imagine a delivery truck which loads parcels without checking their weight first, then drives the truck onto a weigh machine (profiling), then if the truck is overweight they unload each parcel, weigh them individually, find the one heavy one filled with lead weights, then repack the truck without it. That would be silly and inefficient, right? Now imagine they unload the truck and there's no single parcel which is surprisingly heavy and instead the goods have been packed with 'lead foam'. Who could forsee that would cause problems with the weight on the delivery truck? (Anyone!). Now what's the fix? Unpack and repack every parcel, rewrite the whole code. There's no accidentally quadratic here to remove, instead every tiny piece takes a few more microseconds than it needs to and those add up. Another objection is "YOU FOCUSED ON IT' - this implies that there is some way you can design and write code that doesn't need any focus. Part of the point of the video is that the faster code is not harder to write, there's no complex algorithms, no compiler intrinsics, no deep knowledge; it doesn't take a focused performance expert to write a switch(){} instead of a subclass. Another objection is your implication that performance shouldn't be a consideration until you measure it and find a problem, and prove that it is. Which is like saying that aeroplane design weight doesn't matter until after you build it and measure it and prove that it matters. Computers are finite and limited, why have we got to the stage of assuming they are infinite and unlimited, and then demanding proof that they aren't, over and over on a case-by-case basis? A 3D game can render a virtual world at 100 frames per second. Does a program which takes 3 seconds to show a username/password login prompt need enough resources for 300 frames of game until proven otherwise? Another objection is that you are defaulting to 'clean code is the default, performant code needs measuring and benchmarking to justify itself in every individual case. Why isn't that the other way around? Less resource-wasting code as the default, and 'clean code' only when maintainability has been measured and proved to be a problem, and only in the parts of the codebase which have the highest maintainability problems? If all the clean code, encapsulation, isolation, abstraction layers, are providing the developer benefits that are claimed - why aren't programs better? If it's now so clean and easy to refactor, why doesn't that translate to software that gets better instead of software that gets worse? Casey's example is that Visual Studio debugger updated the watch window in realtime while stepping through code, on single core Pentium 4 with 512MB RAM, and now on a modern multicore machine with 64GB RAM and an M2 SSD it can't do that. (RemedyBG can, so it's not impossible).
- jodrellblank 21d ago
  Another small objection that I just remembered, Casey has an interview with Rico Mariani[1] who worked on performance at Microsoft for two decades, from their first C++ compiler, to .NET, to web browsers. He coined the phrase "pit of success" after his team had spent months profiling and tuning the .NET startup to remove many milliseconds from it. One developer on another team called a default constructor for an XML class, and in that commit wiped out all their gains, three times over, he didn't know the default path was slow and there was another way. Rico was giving a talk and said that isn't a good way to design things, success can't be the hard way that only a few experts can find, it has to be like 'falling into a pit', the default way to do things has to be the good way. Anyway, with one browser related performance regression, they profiled and found that the layout engine was using a lot more CPU. He believed the layout engine was good enough, looked elsewhere and found a commit which invalidated a node in a tree and all subnodes. That was cheap and didn't stand out in the trace, but far away in the codebase it triggered a lot of layout updates. Separating things out to focus on just one part at a time, and then the profiler can reveal where the problems are, neither of those things worked as intended. [1] https://www.youtube.com/watch?v=48Rig6v-xYU https://www.youtube.com/watch?v=48Rig6v-xYU
  - deleted 20d ago
    [deleted]

jodrellblank 21d ago

I object on a few fronts. One is that the rewrite has 'mechanical sympathy' with the machine e.g. arrays without pointer chasing can fit more data in CPU cache with fewer stalls while it reads over the main memory bus and waits after every item. That should not be a surprise, it's knowable in advance. Why deliberately ignore knowledge about the machine when designing the code, then come back and use that knowledge? Another objection is to the idea of "measure then improve". Imagine a delivery truck which loads parcels without checking their weight first, then drives the truck onto a weigh machine (profiling), then if the truck is overweight they unload each parcel, weigh them individually, find the one heavy one filled with lead weights, then repack the truck without it. That would be silly and inefficient, right? Now imagine they unload the truck and there's no single parcel which is surprisingly heavy and instead the goods have been packed with 'lead foam'. Who could forsee that would cause problems with the weight on the delivery truck? (Anyone!). Now what's the fix? Unpack and repack every parcel, rewrite the whole code. There's no accidentally quadratic here to remove, instead every tiny piece takes a few more microseconds than it needs to and those add up. Another objection is "YOU FOCUSED ON IT' - this implies that there is some way you can design and write code that doesn't need any focus. Part of the point of the video is that the faster code is not harder to write, there's no complex algorithms, no compiler intrinsics, no deep knowledge; it doesn't take a focused performance expert to write a switch(){} instead of a subclass. Another objection is your implication that performance shouldn't be a consideration until you measure it and find a problem, and prove that it is. Which is like saying that aeroplane design weight doesn't matter until after you build it and measure it and prove that it matters. Computers are finite and limited, why have we got to the stage of assuming they are infinite and unlimited, and then demanding proof that they aren't, over and over on a case-by-case basis? A 3D game can render a virtual world at 100 frames per second. Does a program which takes 3 seconds to show a username/password login prompt need enough resources for 300 frames of game until proven otherwise? Another objection is that you are defaulting to 'clean code is the default, performant code needs measuring and benchmarking to justify itself in every individual case. Why isn't that the other way around? Less resource-wasting code as the default, and 'clean code' only when maintainability has been measured and proved to be a problem, and only in the parts of the codebase which have the highest maintainability problems? If all the clean code, encapsulation, isolation, abstraction layers, are providing the developer benefits that are claimed - why aren't programs better? If it's now so clean and easy to refactor, why doesn't that translate to software that gets better instead of software that gets worse? Casey's example is that Visual Studio debugger updated the watch window in realtime while stepping through code, on single core Pentium 4 with 512MB RAM, and now on a modern multicore machine with 64GB RAM and an M2 SSD it can't do that. (RemedyBG can, so it's not impossible).

jodrellblank 21d ago
Another small objection that I just remembered, Casey has an interview with Rico Mariani[1] who worked on performance at Microsoft for two decades, from their first C++ compiler, to .NET, to web browsers. He coined the phrase "pit of success" after his team had spent months profiling and tuning the .NET startup to remove many milliseconds from it. One developer on another team called a default constructor for an XML class, and in that commit wiped out all their gains, three times over, he didn't know the default path was slow and there was another way. Rico was giving a talk and said that isn't a good way to design things, success can't be the hard way that only a few experts can find, it has to be like 'falling into a pit', the default way to do things has to be the good way. Anyway, with one browser related performance regression, they profiled and found that the layout engine was using a lot more CPU. He believed the layout engine was good enough, looked elsewhere and found a commit which invalidated a node in a tree and all subnodes. That was cheap and didn't stand out in the trace, but far away in the codebase it triggered a lot of layout updates. Separating things out to focus on just one part at a time, and then the profiler can reveal where the problems are, neither of those things worked as intended. [1] https://www.youtube.com/watch?v=48Rig6v-xYU https://www.youtube.com/watch?v=48Rig6v-xYU
- deleted 20d ago
  [deleted]