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
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. :)
"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.
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.
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.
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.