A lot of my graduate work was in the area of parallel computing so we spent a lot of time with Amdahl's law.  Amdahl's law states that if you can speed up some fraction F of the program by some speedup S, the overall speedup of the program is:

1 / [ ( 1 - F ) + ( F / S ) ]

So if you can speed up half the program by 8x, F = 0.5 and S = 8, the overall speed up is only about 1.8x.

By the same token, if you profile a program and find that you can really speed up a part of your program that is only 5% of inclusive time, the best possible speedup is 1.05x.  The moral of the story of course is that you should focus your effort on optimizations that will affect the greatest possible portion of the program.

Which leads me to the question of really long sampling runs.  One thing we've noticed about our users is that they tend to run their app for a really long time under the sampler.  I'm not sure I understand this technique.  You can get a statistically significant number of samples pretty quickly.  Remember that you can use vsperfcmd with the -timer option to set the sampling frequency but even with the default on most processors you are going to get several thousand samples even in a few seconds.  That should be more than enough to tell you where the hot section of your program is.  It doesn't really matter if you get enough samples to tell if some part of your code is 0.5% of your inclusive time or if it's actually 0.7% because Amdahl says you should be ignoring it anyways.  Likewise, you won't care if another function is 50% or 53% of samples because you know that's the bit that needs to be fixed.

I asked RicoM about this a few days ago and he told me that he brings people in to the MSFT developers labs, warms their apps up and then just takes about 15 seconds worth of samples and its usually enough to find where all the allocations / time is coming from.  One possible reason that he suggested where this might be a useful scenario is when you are trying to figure out why an app runs well in the first hour but then slows down in the second hour, so you might want a longer run to try to catch whatever changes.

But it's certainly possible that I'm missing something...  Does anyone have a good reason to do longer runs for everyday sampling jobs?