5 ms·

Also remember that the maximum speedup your program can get from a particular optimization is related to the total time your program spends executing that part.

Also remember that the maximum speedup your program can get from a particular optimization is related to the total time your program spends executing that part. You can speed up an algorithm 1000 fold but if it only accounts for 1% of your total execution time you've only gained a 1% speedup.

collinf 8y ago
Amdahl's law, for further reading. [0] [0] https://en.wikipedia.org/wiki/Amdahl%27s_law https://en.wikipedia.org/wiki/Amdahl%27s_law
paulddraper 8y ago
Exactly. Carrying the logic a step further, that means you should focus first on the longest part of the program. And confidently knowing the longest part of the program requires measuring it. QED
- taeric 8y ago
  Not necessarily longest, though. Right? Most executed would also suffice. Beware measuring, though. Sometimes, just thinking about the problem ahead of time can clearly expose where you are spending time. At least, it can give a hypothesis to test for where you are spending time. With measurements to confirm/refute. :)
  - paulddraper 8y ago
    > Not necessarily longest, though. Right? Most executed would also suffice "Longest total." I don't care if its a big slice of pie or a lot of little slices. But it better be one of those. > Sometimes, just thinking about the problem ahead of time can clearly expose where you are spending time. That's certainly true. But 99% of people overestimate their ability to do this. And are surprised by the results.
    - CarolineW 8y ago
      So when you say "longest" you don't mean "longest section of code", I'm guessing you mean "section of code in which execution spends the longest time". If so, good, but it wasn't clear to me that that's what you meant. If you mean something else then I don't know what you mean at all.
      - paulddraper 8y ago
        "Longest" seemed clear to me. (Over "largest" and "slowest".)
        CarolineW 8y ago
        But you wrote it, so of course it's clear to you. To me, when someone says "the longest part of the program" I immediately think of the routine that stretches over the most lines. That's the longest part of the code.
        PeterisP 8y ago
        IDK, "longest part of code" to me clearly seems to refer to length of the code (i.e. lines of code), not to length of its execution time; so I'd say that there definitely seems to be some confusion caused by the choice of words.
        taeric 8y ago
        Just to further these two posts, that is why I asked my question at the top here. "Hottest" code, I thought, was already well established for most executed. I had never seen "longest" for anything. To that end, I was taking it to mean that longest "synchronous" path through your system. Not necessarily a single method, by any measure. But, systems have plenty of what I will call "checkpoints" where code can be restarted/rerun with no hard to recover penalty. That is what I took to mean by longest.
  - scott_s 8y ago
    > Beware measuring, though. Sometimes, just thinking about the problem ahead of time can clearly expose where you are spending time. Why beware measuring? In my experience, people are generally terrible at guessing where the bulk of the time is being spent. Measure as soon as you care.
    - taeric 8y ago
      Apologies, I meant that as blind measuring. Don't just get a reading and take action. Hypothesize about where you think the time is spent and measure to test your hypothesis. And always question why the time is spent where it is.
- deleted 8y ago
  [deleted]
coldtea 8y ago
>You can speed up an algorithm 1000 fold but if it only accounts for 1% of your total execution time you've only gained a 1% speedup. In a pure program, yes. In an impure one, not necessarily. The change in algorithm could result in some different data structures or layout, and this could cause another part of the program to run much faster or slower (e.g. because of cache locality issues).
justinsaccount 8y ago
I often test out things like this by completely disabling components. It's one way of measuring, and can really help narrow things down in larger programs. i.e., pipeline takes 300s to run. Suspect the final output may be worth profiling and optimizing. Stick a 'return' at the top of the output function and see the pipeline now takes 295s to run. Conclusion: final output not the problem.
- monocasa 8y ago
  Profilers with a flame graph gets you the same information without having to do a manual search through your execution.
  - BeeOnRope 8y ago
    Yes, although it's not exactly the same because there can cross-cutting effects where the behavior of one function affects another. For example, one function thrash the cache, which ends up greatly slowing down a second function. If you remove the first function entirely (comment it out, etc), the change will reflect that, but a flame graph won't (since it only shows the actual runtime for the second function: it has no way to determine how much impact it is having on other functions indirectly).
  - TeMPOraL 8y ago
    Iff your language has one, and it doesn't choke on the codebase...

collinf 8y ago

Amdahl's law, for further reading. [0] [0] https://en.wikipedia.org/wiki/Amdahl%27s_law https://en.wikipedia.org/wiki/Amdahl%27s_law

paulddraper 8y ago

Exactly. Carrying the logic a step further, that means you should focus first on the longest part of the program. And confidently knowing the longest part of the program requires measuring it. QED

taeric 8y ago
Not necessarily longest, though. Right? Most executed would also suffice. Beware measuring, though. Sometimes, just thinking about the problem ahead of time can clearly expose where you are spending time. At least, it can give a hypothesis to test for where you are spending time. With measurements to confirm/refute. :)
- paulddraper 8y ago
  > Not necessarily longest, though. Right? Most executed would also suffice "Longest total." I don't care if its a big slice of pie or a lot of little slices. But it better be one of those. > Sometimes, just thinking about the problem ahead of time can clearly expose where you are spending time. That's certainly true. But 99% of people overestimate their ability to do this. And are surprised by the results.
  - CarolineW 8y ago
    So when you say "longest" you don't mean "longest section of code", I'm guessing you mean "section of code in which execution spends the longest time". If so, good, but it wasn't clear to me that that's what you meant. If you mean something else then I don't know what you mean at all.
    - paulddraper 8y ago
      "Longest" seemed clear to me. (Over "largest" and "slowest".)
      - CarolineW 8y ago
        But you wrote it, so of course it's clear to you. To me, when someone says "the longest part of the program" I immediately think of the routine that stretches over the most lines. That's the longest part of the code.
      - PeterisP 8y ago
        IDK, "longest part of code" to me clearly seems to refer to length of the code (i.e. lines of code), not to length of its execution time; so I'd say that there definitely seems to be some confusion caused by the choice of words.
        taeric 8y ago
        Just to further these two posts, that is why I asked my question at the top here. "Hottest" code, I thought, was already well established for most executed. I had never seen "longest" for anything. To that end, I was taking it to mean that longest "synchronous" path through your system. Not necessarily a single method, by any measure. But, systems have plenty of what I will call "checkpoints" where code can be restarted/rerun with no hard to recover penalty. That is what I took to mean by longest.
- scott_s 8y ago
  > Beware measuring, though. Sometimes, just thinking about the problem ahead of time can clearly expose where you are spending time. Why beware measuring? In my experience, people are generally terrible at guessing where the bulk of the time is being spent. Measure as soon as you care.
  - taeric 8y ago
    Apologies, I meant that as blind measuring. Don't just get a reading and take action. Hypothesize about where you think the time is spent and measure to test your hypothesis. And always question why the time is spent where it is.
deleted 8y ago
[deleted]

coldtea 8y ago

>You can speed up an algorithm 1000 fold but if it only accounts for 1% of your total execution time you've only gained a 1% speedup. In a pure program, yes. In an impure one, not necessarily. The change in algorithm could result in some different data structures or layout, and this could cause another part of the program to run much faster or slower (e.g. because of cache locality issues).

justinsaccount 8y ago

I often test out things like this by completely disabling components. It's one way of measuring, and can really help narrow things down in larger programs. i.e., pipeline takes 300s to run. Suspect the final output may be worth profiling and optimizing. Stick a 'return' at the top of the output function and see the pipeline now takes 295s to run. Conclusion: final output not the problem.

monocasa 8y ago
Profilers with a flame graph gets you the same information without having to do a manual search through your execution.
- BeeOnRope 8y ago
  Yes, although it's not exactly the same because there can cross-cutting effects where the behavior of one function affects another. For example, one function thrash the cache, which ends up greatly slowing down a second function. If you remove the first function entirely (comment it out, etc), the change will reflect that, but a flame graph won't (since it only shows the actual runtime for the second function: it has no way to determine how much impact it is having on other functions indirectly).
- TeMPOraL 8y ago
  Iff your language has one, and it doesn't choke on the codebase...