4 ms·

As for #1 and #2, you really DO need to measure. Over the years I've spent a lot of time optimizing other people's code and many performance problems are quasi-

As for #1 and #2, you really DO need to measure. Over the years I've spent a lot of time optimizing other people's code and many performance problems are quasi-bugs. Doing things like inserting data into sorted data structures (as opposed to doing all your inserts and THEN sorting) aren't so much "This is an obvious hot spot from the problem definition" as "A poor decision made this a hot spot." Profiling finds this sort of low hanging fruit quite easily.

marcosdumay 3y ago
So, you had a performance bomb somewhere. That doesn't change the fact that you know beforehand what kind of problem takes a lot of CPU time and what doesn't. Profiling doesn't find things of the kind of "this takes a lot of computer time, we should program everything around it"; "this takes a lot of computer time, are you sure we can run it profitably?"; or "this takes a lot of memory, are we willing to get new servers?". Besides, the worst moment to optimize your code is after everything is written and people depend on its interface. Profiling is some duck tape you can use to cover small problems, and mostly only that.
- shadowgovt 3y ago
  > you know beforehand what kind of problem takes a lot of CPU time and what doesn't Do you? Do you really know the ins and outs of the optimizations of the CPU you're going to be running on? If you do, you're in a specific domain that may not match to many other developers today. Modern CPUs are incredibly complex machines running emulation of a PDP-11 single-threaded architecture. If you're starting from the beginning with a belief that you know what the source code you write is going to do on the CPU to a level of precision that means you can skip rule 1 and 2... Most people who believe that are flatly wrong. And if you aren't, you're probably doing embedded computing, which follows its own set of rules (Rob's rules are a lot more tuned to business, cloud, and consumer-desktop-environment computing). > the worst moment to optimize your code is after everything is written and people depend on its interface. Honestly, that's exactly opposite of my experience. The interface is designed apart from the machine, and as a software engineer it's my job to fit the machine to that interface. Because the user matters most.
  - marcosdumay 3y ago
    > Do you? If you didn't, you wouldn't know the broken code needed fixing. How do you differentiate code that is using the wrong data structure from the one that is solving a hard problem?
    - shadowgovt 3y ago
      > How do you differentiate code that is using the wrong data structure from the one that is solving a hard problem? You don't until you have to. At the limit, every piece of code is using the wrong data structure; the hardest problems get addressed by building custom hardware to maximize speed by stripping away every other possible concern in the transformation of the symbols and building as many of those as you possibly can force to work in parallel. Almost nothing is that important, so when your program is too slow, you search for what is taking the most time and do the cost/benefit analysis of re-representing the problem in a way that matches the existing hardware better (which encompasses everything from requiring fewer steps in the computation to caching the right data to caching the right data in the right location, i.e. L0-L1 cache performance, all the way to, sometimes, pushing the computation onto a GPU or out into multiple parallel execution nodes in a cluster if the problem demands it). None of this is black-and-white and there are degrees. You can certainly, during the design phase, look at a problem and go "That's probably going to want a cluster." But the point of Pike's 1 and 2 is "If you don't have a firm reason to believe a more complicated approach should be taken, err on the side of the simpler approach because it's easier to grow a simpler approach than move a complicated approach."
      - marcosdumay 3y ago
        > At the limit, every piece of code is using the wrong data structure So, at the example you commented earlier, you inspect every single function, sorted by execution time until the program was fast enough? > do the cost/benefit analysis of re-representing the problem How do you do that without knowing the speed you can get with another representation? You rewrite it on every possible way and test? > But the point of Pike's 1 and 2 is "If you don't have a firm reason to believe a more complicated approach should be taken, err on the side of the simpler approach Yet we are what, 5 messages down a thread where people vehemently deny you can't have reason to believe anything.

marcosdumay 3y ago

So, you had a performance bomb somewhere. That doesn't change the fact that you know beforehand what kind of problem takes a lot of CPU time and what doesn't. Profiling doesn't find things of the kind of "this takes a lot of computer time, we should program everything around it"; "this takes a lot of computer time, are you sure we can run it profitably?"; or "this takes a lot of memory, are we willing to get new servers?". Besides, the worst moment to optimize your code is after everything is written and people depend on its interface. Profiling is some duck tape you can use to cover small problems, and mostly only that.

shadowgovt 3y ago
> you know beforehand what kind of problem takes a lot of CPU time and what doesn't Do you? Do you really know the ins and outs of the optimizations of the CPU you're going to be running on? If you do, you're in a specific domain that may not match to many other developers today. Modern CPUs are incredibly complex machines running emulation of a PDP-11 single-threaded architecture. If you're starting from the beginning with a belief that you know what the source code you write is going to do on the CPU to a level of precision that means you can skip rule 1 and 2... Most people who believe that are flatly wrong. And if you aren't, you're probably doing embedded computing, which follows its own set of rules (Rob's rules are a lot more tuned to business, cloud, and consumer-desktop-environment computing). > the worst moment to optimize your code is after everything is written and people depend on its interface. Honestly, that's exactly opposite of my experience. The interface is designed apart from the machine, and as a software engineer it's my job to fit the machine to that interface. Because the user matters most.
- marcosdumay 3y ago
  > Do you? If you didn't, you wouldn't know the broken code needed fixing. How do you differentiate code that is using the wrong data structure from the one that is solving a hard problem?
  - shadowgovt 3y ago
    > How do you differentiate code that is using the wrong data structure from the one that is solving a hard problem? You don't until you have to. At the limit, every piece of code is using the wrong data structure; the hardest problems get addressed by building custom hardware to maximize speed by stripping away every other possible concern in the transformation of the symbols and building as many of those as you possibly can force to work in parallel. Almost nothing is that important, so when your program is too slow, you search for what is taking the most time and do the cost/benefit analysis of re-representing the problem in a way that matches the existing hardware better (which encompasses everything from requiring fewer steps in the computation to caching the right data to caching the right data in the right location, i.e. L0-L1 cache performance, all the way to, sometimes, pushing the computation onto a GPU or out into multiple parallel execution nodes in a cluster if the problem demands it). None of this is black-and-white and there are degrees. You can certainly, during the design phase, look at a problem and go "That's probably going to want a cluster." But the point of Pike's 1 and 2 is "If you don't have a firm reason to believe a more complicated approach should be taken, err on the side of the simpler approach because it's easier to grow a simpler approach than move a complicated approach."
    - marcosdumay 3y ago
      > At the limit, every piece of code is using the wrong data structure So, at the example you commented earlier, you inspect every single function, sorted by execution time until the program was fast enough? > do the cost/benefit analysis of re-representing the problem How do you do that without knowing the speed you can get with another representation? You rewrite it on every possible way and test? > But the point of Pike's 1 and 2 is "If you don't have a firm reason to believe a more complicated approach should be taken, err on the side of the simpler approach Yet we are what, 5 messages down a thread where people vehemently deny you can't have reason to believe anything.