6 ms·

> That's really not even close to true. Loading random websites frequently costs multiple seconds worth of (...) You attempted to present an argument that's a

> That's really not even close to true. Loading random websites frequently costs multiple seconds worth of (...) You attempted to present an argument that's a textbook example of an hyperbolic fallacy. There are worlds of difference between "this code does not sit in a hot path" and "let's spend multiple seconds of local processing time". This blend of specious reasoning is the reason why the first rule of software optimization is "don't". Proponents of mindlessly going about the 1% edge cases fail to understand that the whole world is comprised of the 99% of cases where shaving off that millisecond buys you absolutely nothing, with a tradeoff of producing unmaintainable code. The truth of the matter is that in 99% of the cases there is absolutely no good reason to run after these relatively large performance improvements if in the end the user notices absolutely nothing. Moreso if you're writing async code that stays far away from any sort of hot path.

heisenbit 4y ago
How does an organization which has been built on 99% not doing optimization recognize the one percent where it matters a lot?
- eropple 4y ago
  In my experience: a profiler, usually. Just because I can throw down a lot of code quickly doesn't mean I don't have the tools to analyze code when I go "hmm, that seems slow".
  - incrudible 4y ago
    That works for big hotspots, but not for the tiny papercuts that make every little thing 10x slower.
    - eropple 4y ago
      Sure. That's a tradeoff you consciously make to get the thing out the door. That's what technical debt is. You pay it down later. (Or you go bankrupt and it doesn't matter anymore.)
      - incrudible 4y ago
        The blog post challenges the assumption that the slower version is any way improving productivity. At least for the given example, I agree.
- Turskarama 4y ago
  Testing, do you not do testing? Use the software. If it seems slow drill down and find the critical path and optimize it.
  - yuliyp 4y ago
    Testing is often not enough. Developers might have a few test cases with a few records, or a few other users. Real users might do more with it, and things which perform fine in testing suddenly turn into real performance bottlenecks when you're loading an order list with a thousand entries in it instead of two.
    - Turskarama 4y ago
      When I said testing that includes integration testing, not just unit tests. We do this exact thing with queries that are known to be complex, run them against databases the same size and complexity as real production databases. It's not hard.
      - rerdavies 4y ago
        Building representative databases is not straightforward. If you're lucky enough to eat your own dogfood, run unit tests against a copy(!) of your in-house database. A utility to anonymize the data was a fairly significant investment, but absolutely worth it in the long run. Being able to run and monitor benchmark unit tests for selected critical operations on enterprise-scale test data as part of the continuous-build process: fabulous!
- julik 4y ago
  By someone presenting plausible evidence that not having that 1% optimised costs the organization money/business, and leadership that would listen
- saagarjha 4y ago
  In any organization it generally pays off to have most people have a basic knowledge of a subject and then hire domain experts to drive most of the impact. For security, for example, this typically manifests as having very general "best practices" for most developers to follow and then a small team that handles anything that requires advanced understanding of the area. How this typically works with performance is very similar, with a small team working to identify problematic areas where optimization would drive the highest impact, and the rest of the organization keeping performance in mind but not otherwise concerned with it in their day-to-day work.
- simplotek 4y ago
  > How does an organization which has been built on 99% not doing optimization recognize the one percent where it matters a lot? If you can't recognize the percent where it matters a lot, clearly that percent does not exist and you're bothering about nothing. I see a lot of talk about the importance of tuning Formula 1 cars in a world where everyone drives ford fiestas.
- rerdavies 4y ago
  Profiling. If you're not profiling, you're completely wasting your time. The 1% is almost never where you think it is. And when you do identify the 1%, you need to be testing optimizations with a profiler constantly while optimizing. Profile. Do some optimization. Profile again. Roll back if not successful. Repeat until done. It's impossible to optimize well if you're not doing profiling. The ultimate tools would be either Intel's profiling tools, or ARM's profiling suite (both very expensive). But MSVC and GCC do a fantastic job of scheduling instructions to avoid pipeline stalls these days, so these deep profiling tools are unlikely to gain more than 2 or 3% performance increases these days. (Worthwhile pretty much only if you're writing GPU drivers for NVidia or AMD). Taken as a given that 100% of your code is at least algorithmically correct in the first place. (Appropriately better than O(N^2) whenever possible). - Former writer of graphics drivers, currently audio DSP engineer.
  - anonymoushn 4y ago
    A hash table that accesses a minimum of 2 cache lines per query can be algorithmically correct and also admit a 100% speedup.
  - themulticaster 4y ago
    I'm not familiar with how it compares to ARM/Intel's profiling tools, but I found the Linux perf suite to be very capable (though limited to Linux obviously). And Hotspot [1] allows effortless profile visualization using flame graphs, including some very interesting features such as off-CPU time profiling [2]. "perf record" coupled with Hotspot forms a very smooth edit-compile-profile cycle. [1] https://github.com/KDAB/hotspot https://github.com/KDAB/hotspot [2] https://github.com/KDAB/hotspot#off-cpu-profiling https://github.com/KDAB/hotspot#off-cpu-profiling
    - rerdavies 4y ago
      Agreed. Linux perf tools are perfectly acceptable for all but the most ultra-extreme optimization tasks. VTune allows you to determine where pipeline stalls are occurring at the instruction level (for that last 2 or 3% gain in performance). I haven't worked with ARM profilers (way out of my price range), but I assume, given the exorbitant price, they provide the same sort of in-depth analysis. Probably a handful of people on the planet that need that kind of in-depth analysis.
loup-vaillant 4y ago
I realised when I implemented EdDSA for Monocypher that optimisations compound. When I got rid of a bottleneck, I noticed that another part of the code was the new bottleneck, and some of the optimisations compounded multiplicatively. It took many changes before I finally started to hit diminishing returns and stop. All while restricting myself to standard C99, and trying fairly hard not to spend too many lines of code on this. My point being, if most of the program is slowed down by a slew of wasted CPU cycles (costly abstractions, slow interpreted language…), there's a good chance what should have been obvious bottlenecks get drowned in a see of underperformance. They're harder to spot, and fixing them doesn't change much. So before you even get to actual optimisation, your program should be fast enough that actual optimisations have a real impact. And yes, actual optimisation should be done quite rarely. But first, we need to make sure our programs aren't as slow as molasses. See https://www.youtube.com/watch?v=pgoetgxecw8 https://www.youtube.com/watch?v=pgoetgxecw8
- simplotek 4y ago
  > I realised when I implemented EdDSA for Monocypher that optimisations compound. I feel you're missing the whole point. It's immaterial whether anyone can get to optimizations that compound multiplicatively. The whole point is that halving something that costs nothing earns you nothing. That's the whole point. Go ahead and shave off that millisecond. Will anyone actually notice whether you add or remove that penalty? Odds are, not at all.
  - loup-vaillant 4y ago
    People did notice. Quite a few happy users are glad signature verification took less than a second instead of more than 3. Or 30, if you compare to some of the alternatives. Others love the fact it uses 2KB of stack space instead of 5. Monocypher's speed was actually an important component in its success in the embedded market, even though I didn't explicitly target it initially (I was lucky my portability driven decisions made it a good fit there).
    - tharkun__ 4y ago
mquander 4y ago
The subfields of programming I know the most about are game development, networking, and web development, and in all of those, it's not the case that only 1% of the code is in the "edge case" where performance matters at all. For example, in the case of web development, if you build a medium-sized website with React (i.e. pretty normal behavior nowadays), then if you make default decisions that don't consider performance at all, your website will end up noticeably slow, because you will: 1. Write code that re-renders components all the time during loading and UI interactions, 2. Which depend on tons of third-party dependencies that perform poorly, 3. So you end up spending a ton of time in re-renders while the site loads and while someone is using it. Dealing with this isn't literally the same performance work that Casey put in his article, because it's at a slightly higher level of abstraction, but it requires the same mindset. It requires writing most of your code (and taking on dependencies) with performance in mind, not just 1% of it. You can't avoid it without your notion of "clean code" including some amount of mechanical sympathy, rather than just being about abstract extensibility and generalization concerns.
- whstl 4y ago
  It's also very easy to mess up the performance due to architecture when using modern frameworks. For example: as much as SPAs are reviled, if you have a complex enough web application with heavy components, having it being an SPA might be better in terms of perceived speed than having it do a full reload on every navigation. This is a mistake that I see far too many government and utility sites making.
- Aeolun 4y ago
  Except that in React writing clean code will actually make your application faster.
- engineeringwoke 4y ago
  Re-renders are incredibly cheap in the big picture. They are not a source of performance bottlenecks in 99% of real world applications
  - xtian 4y ago
mtrower 4y ago
> the whole world is comprised of the 99% of cases where shaving off that millisecond buys you absolutely nothing Who was talking about a single millisecond here? I notice, broadly, two types of people who engage in these arguments. 1> OMG, computers are thousands of times faster than they were a decade ago, why is everything not lightning fast? Why are so many things slower than they were back then? Why is my chat program eating 2GB(!) of RAM? 2> Because we're busy writing six billion features on our Nth iteration of this problem space, we can't be bothered to shave a few millis bro! And they just talk past each other.

heisenbit 4y ago

How does an organization which has been built on 99% not doing optimization recognize the one percent where it matters a lot?

eropple 4y ago
In my experience: a profiler, usually. Just because I can throw down a lot of code quickly doesn't mean I don't have the tools to analyze code when I go "hmm, that seems slow".
- incrudible 4y ago
  That works for big hotspots, but not for the tiny papercuts that make every little thing 10x slower.
  - eropple 4y ago
    Sure. That's a tradeoff you consciously make to get the thing out the door. That's what technical debt is. You pay it down later. (Or you go bankrupt and it doesn't matter anymore.)
    - incrudible 4y ago
      The blog post challenges the assumption that the slower version is any way improving productivity. At least for the given example, I agree.
Turskarama 4y ago
Testing, do you not do testing? Use the software. If it seems slow drill down and find the critical path and optimize it.
- yuliyp 4y ago
  Testing is often not enough. Developers might have a few test cases with a few records, or a few other users. Real users might do more with it, and things which perform fine in testing suddenly turn into real performance bottlenecks when you're loading an order list with a thousand entries in it instead of two.
  - Turskarama 4y ago
    When I said testing that includes integration testing, not just unit tests. We do this exact thing with queries that are known to be complex, run them against databases the same size and complexity as real production databases. It's not hard.
    - rerdavies 4y ago
      Building representative databases is not straightforward. If you're lucky enough to eat your own dogfood, run unit tests against a copy(!) of your in-house database. A utility to anonymize the data was a fairly significant investment, but absolutely worth it in the long run. Being able to run and monitor benchmark unit tests for selected critical operations on enterprise-scale test data as part of the continuous-build process: fabulous!
julik 4y ago
By someone presenting plausible evidence that not having that 1% optimised costs the organization money/business, and leadership that would listen
saagarjha 4y ago
In any organization it generally pays off to have most people have a basic knowledge of a subject and then hire domain experts to drive most of the impact. For security, for example, this typically manifests as having very general "best practices" for most developers to follow and then a small team that handles anything that requires advanced understanding of the area. How this typically works with performance is very similar, with a small team working to identify problematic areas where optimization would drive the highest impact, and the rest of the organization keeping performance in mind but not otherwise concerned with it in their day-to-day work.
simplotek 4y ago
> How does an organization which has been built on 99% not doing optimization recognize the one percent where it matters a lot? If you can't recognize the percent where it matters a lot, clearly that percent does not exist and you're bothering about nothing. I see a lot of talk about the importance of tuning Formula 1 cars in a world where everyone drives ford fiestas.
rerdavies 4y ago
Profiling. If you're not profiling, you're completely wasting your time. The 1% is almost never where you think it is. And when you do identify the 1%, you need to be testing optimizations with a profiler constantly while optimizing. Profile. Do some optimization. Profile again. Roll back if not successful. Repeat until done. It's impossible to optimize well if you're not doing profiling. The ultimate tools would be either Intel's profiling tools, or ARM's profiling suite (both very expensive). But MSVC and GCC do a fantastic job of scheduling instructions to avoid pipeline stalls these days, so these deep profiling tools are unlikely to gain more than 2 or 3% performance increases these days. (Worthwhile pretty much only if you're writing GPU drivers for NVidia or AMD). Taken as a given that 100% of your code is at least algorithmically correct in the first place. (Appropriately better than O(N^2) whenever possible). - Former writer of graphics drivers, currently audio DSP engineer.
- anonymoushn 4y ago
  A hash table that accesses a minimum of 2 cache lines per query can be algorithmically correct and also admit a 100% speedup.
- themulticaster 4y ago
  I'm not familiar with how it compares to ARM/Intel's profiling tools, but I found the Linux perf suite to be very capable (though limited to Linux obviously). And Hotspot [1] allows effortless profile visualization using flame graphs, including some very interesting features such as off-CPU time profiling [2]. "perf record" coupled with Hotspot forms a very smooth edit-compile-profile cycle. [1] https://github.com/KDAB/hotspot https://github.com/KDAB/hotspot [2] https://github.com/KDAB/hotspot#off-cpu-profiling https://github.com/KDAB/hotspot#off-cpu-profiling
  - rerdavies 4y ago
    Agreed. Linux perf tools are perfectly acceptable for all but the most ultra-extreme optimization tasks. VTune allows you to determine where pipeline stalls are occurring at the instruction level (for that last 2 or 3% gain in performance). I haven't worked with ARM profilers (way out of my price range), but I assume, given the exorbitant price, they provide the same sort of in-depth analysis. Probably a handful of people on the planet that need that kind of in-depth analysis.

loup-vaillant 4y ago

I realised when I implemented EdDSA for Monocypher that optimisations compound. When I got rid of a bottleneck, I noticed that another part of the code was the new bottleneck, and some of the optimisations compounded multiplicatively. It took many changes before I finally started to hit diminishing returns and stop. All while restricting myself to standard C99, and trying fairly hard not to spend too many lines of code on this. My point being, if most of the program is slowed down by a slew of wasted CPU cycles (costly abstractions, slow interpreted language…), there's a good chance what should have been obvious bottlenecks get drowned in a see of underperformance. They're harder to spot, and fixing them doesn't change much. So before you even get to actual optimisation, your program should be fast enough that actual optimisations have a real impact. And yes, actual optimisation should be done quite rarely. But first, we need to make sure our programs aren't as slow as molasses. See https://www.youtube.com/watch?v=pgoetgxecw8 https://www.youtube.com/watch?v=pgoetgxecw8

simplotek 4y ago
> I realised when I implemented EdDSA for Monocypher that optimisations compound. I feel you're missing the whole point. It's immaterial whether anyone can get to optimizations that compound multiplicatively. The whole point is that halving something that costs nothing earns you nothing. That's the whole point. Go ahead and shave off that millisecond. Will anyone actually notice whether you add or remove that penalty? Odds are, not at all.
- loup-vaillant 4y ago
  People did notice. Quite a few happy users are glad signature verification took less than a second instead of more than 3. Or 30, if you compare to some of the alternatives. Others love the fact it uses 2KB of stack space instead of 5. Monocypher's speed was actually an important component in its success in the embedded market, even though I didn't explicitly target it initially (I was lucky my portability driven decisions made it a good fit there).
  - tharkun__ 4y ago

mquander 4y ago

The subfields of programming I know the most about are game development, networking, and web development, and in all of those, it's not the case that only 1% of the code is in the "edge case" where performance matters at all. For example, in the case of web development, if you build a medium-sized website with React (i.e. pretty normal behavior nowadays), then if you make default decisions that don't consider performance at all, your website will end up noticeably slow, because you will: 1. Write code that re-renders components all the time during loading and UI interactions, 2. Which depend on tons of third-party dependencies that perform poorly, 3. So you end up spending a ton of time in re-renders while the site loads and while someone is using it. Dealing with this isn't literally the same performance work that Casey put in his article, because it's at a slightly higher level of abstraction, but it requires the same mindset. It requires writing most of your code (and taking on dependencies) with performance in mind, not just 1% of it. You can't avoid it without your notion of "clean code" including some amount of mechanical sympathy, rather than just being about abstract extensibility and generalization concerns.

whstl 4y ago
It's also very easy to mess up the performance due to architecture when using modern frameworks. For example: as much as SPAs are reviled, if you have a complex enough web application with heavy components, having it being an SPA might be better in terms of perceived speed than having it do a full reload on every navigation. This is a mistake that I see far too many government and utility sites making.
Aeolun 4y ago
Except that in React writing clean code will actually make your application faster.
engineeringwoke 4y ago
Re-renders are incredibly cheap in the big picture. They are not a source of performance bottlenecks in 99% of real world applications
- xtian 4y ago

mtrower 4y ago

> the whole world is comprised of the 99% of cases where shaving off that millisecond buys you absolutely nothing Who was talking about a single millisecond here? I notice, broadly, two types of people who engage in these arguments. 1> OMG, computers are thousands of times faster than they were a decade ago, why is everything not lightning fast? Why are so many things slower than they were back then? Why is my chat program eating 2GB(!) of RAM? 2> Because we're busy writing six billion features on our Nth iteration of this problem space, we can't be bothered to shave a few millis bro! And they just talk past each other.