Return to Answer

You gotta ask why you are profiling.

1. To get general performance measurements.

2. To find ways to make the code go faster yet.

If the answer is 1, then by all means, run your profiler on the optimized code.

If the answer is 2, then don't. Here's why. There are two kinds of speedups, the ones you can do, and the ones the compiler can do.

The compiler cannot find or fix the speedups you can do, such as minimizing memory allocation, memoizing functions that get called with repeat arguments, avoiding innocent-looking library calls that end up doing breezy I/O, on and on.

There is no speed bug you can fix that is made any more evident by the optimizer.

What it can do is make them harder to find by scrambling the code, randomly inlining, getting rid of stack frames, etc.
And keep in mind, the only improvement it can actually make is at the bottom of the call stack, and only if it's in your code. Anything it does higher up the stack is of minimal/negligible benefit.

The strategy some people use is this, and the statistical reason why it works is here. After having done that enough to make the code blazingly fast without the optimizer, then turn on the optimizer to make it faster yet.

You gotta ask why you are profiling.

1. To get general performance measurements.

2. To find ways to make the code go faster yet.

If the answer is 1, then by all means, run your profiler on the optimized code.

If the answer is 2, then don't. Here's why. There are two kinds of speedups, the ones you can do, and the ones the compiler can do.

The compiler cannot find or fix the speedups you can do, such as minimizing memory allocation, memoizing functions that get called with repeat arguments, avoiding innocent-looking library calls that end up doing breezy I/O, on and on.

There is no speed bug you can fix that is made any more evident by the optimizer.

What it can do is make them harder to find by scrambling the code, randomly inlining, getting rid of stack frames, etc.
And keep in mind, the only improvement it can actually make is at the bottom of the call stack, and only if it's in your code. Anything it does higher up the stack is of minimal/negligible benefit.

The strategy some people use is this, and the statistical reason why it works is here. After having done that enough to make the code blazingly fast without the optimizer, then turn on the optimizer to make it faster yet.

You gotta ask why you are profiling.

1. To get general performance measurements.

2. To find ways to make the code go faster yet.

If the answer is 1, then by all means, run your profiler on the optimized code.

If the answer is 2, then don't. Here's why. There are two kinds of speedups, the ones you can do, and the ones the compiler can do.

The compiler cannot find or fix the speedups you can do, such as minimizing memory allocation, memoizing functions that get called with repeat arguments, avoiding innocent-looking library calls that end up doing breezy I/O, on and on.

There is no speed bug you can fix that is made any more evident by the optimizer.

What it can do is make them harder to find by scrambling the code, randomly inlining, getting rid of stack frames, etc.
And keep in mind, the only improvement it can actually make is at the bottom of the call stack, and only if it's in your code. Anything it does higher up the stack is of minimal/negligible benefit.

The strategy some people use is this, and the statistical reason why it works is here. After having done that enough to make the code blazingly fast without the optimizer, then turn on the optimizer to make it faster yet.

You gotta ask why you are profiling.

1. To get general performance measurements.

2. To find ways to make the code go faster yet.

If the answer is 1, then by all means, run your profiler on the optimized code.

If the answer is 2, then don't. Here's why. There are two kinds of speedups, the ones you can do, and the ones the compiler can do.

The compiler cannot find or fix the speedups you can do, such as minimizing memory allocation, memoizing functions that get called with repeat arguments, avoiding innocent-looking library calls that end up doing breezy I/O, on and on.

There is no speed bug you can fix that is made any more evident by the optimizer.

What it can do is make them harder to find by scrambling the code, randomly inlining, getting rid of stack frames, etc.
And keep in mind, the only improvement it can actually make is at the bottom of the call stack, and only if it's in your code. Anything it does higher up the stack is of minimal/negligible benefit.

The strategy some people use is this, and the statistical reason why it works is here. After having done that enough to make the code blazingly fast without the optimizer, then turn on the optimizer to make it faster yet.

You gotta ask why you are profiling.

1. To get general performance measurements.

2. To find ways to make the code go faster yet.

If the answer is 1, then by all means, run your profiler on the optimized code.

If the answer is 2, then don't. Here's why. There are two kinds of speedups, the ones you can do, and the ones the compiler can do.

The compiler cannot find or fix the speedups you can do, such as minimizing memory allocation, memoizing functions that get called with repeat arguments, avoiding innocent-looking library calls that end up doing breezy I/O, on and on.

There is no speed bug you can fix that is made any more evident by the optimizer.

What it can do is make them harder to find by scrambling the code, randomly inlining, getting rid of stack frames, etc.
Added: And keep in mind, the only improvement it can actually make is at the bottom of the call stack, and only if it's in your code. Anything it does higher up the stack is of minimal/negligible benefit.

The strategy some people use is this, and the statistical reason why it works is here. After having done that enough to make the code blazingly fast without the optimizer, then turn on the optimizer to make it faster yet.

You gotta ask why you are profiling.

1. To get general performance measurements.

2. To find ways to make the code go faster yet.

If the answer is 1, then by all means, run your profiler on the optimized code.

If the answer is 2, then don't. Here's why. There are two kinds of speedups, the ones you can do, and the ones the compiler can do.

The compiler cannot find or fix the speedups you can do, such as minimizing memory allocation, memoizing functions that get called with repeat arguments, avoiding innocent-looking library calls that end up doing breezy I/O, on and on.

There is no speed bug you can fix that is made any more evident by the optimizer.

What it can do is make them harder to find by scrambling the code, randomly inlining, getting rid of stack frames, etc.
And keep in mind, the only improvement it can actually make is at the bottom of the call stack, and only if it's in your code. Anything it does higher up the stack is of minimal/negligible benefit.

The strategy some people use is this, and the statistical reason why it works is here. After having done that enough to make the code blazingly fast without the optimizer, then turn on the optimizer to make it faster yet.