Assuming the frame pointer cost 1% of additional runtime.
if frame pointer is enabled allow profiling wich result 5% because easyness of profiling, enabling frame pointer result in a net speed increase of 4% of the whole program.
The counter-argument is that 99% of people aren’t profiling. So why pay 1% for users of a program if they are not profiling it? In an ideal world it would be easy to flip between frame-pointers for developer workstations and no frame-pointers for end-users who will never profile a single binary in their lifetime.
Of course the real-world is messy. Especially if you can do something like having a low rate of sampling profiling running on end-user machines which could very easily save 1% by fixing performance for real-world cases.
Often you can only see the real problem with real data (in production), therefore it is very valuable to be able to profile where the data is without changing the system significantly.
Having to reboot into a different distro that has profiling enabled means that you may lose the reproduction of a (performance) bug.
Sure, you may be able to reproduce the problem in the lab, but the same logic applies there (you want to run most of your testing with the exact binaries that users will use, not with a substantially different one that has frame pointers).
There’s some irony here: deciding to remove the thing that lets you more easily analyse performance problems and implement performance improvements… in order to improve performance. I wonder whether the 1-2% wins gained by enabling them are compensated, across the industry, by the lost potential for performance win discovery. Somehow, I doubt it.
Assuming the frame pointer cost 1% of additional runtime.
if frame pointer is enabled allow profiling wich result 5% because easyness of profiling, enabling frame pointer result in a net speed increase of 4% of the whole program.
The counter-argument is that 99% of people aren’t profiling. So why pay 1% for users of a program if they are not profiling it? In an ideal world it would be easy to flip between frame-pointers for developer workstations and no frame-pointers for end-users who will never profile a single binary in their lifetime.
Of course the real-world is messy. Especially if you can do something like having a low rate of sampling profiling running on end-user machines which could very easily save 1% by fixing performance for real-world cases.
in my scenario, 100% of the users will benefit of the 4% of speed improvement. vs 100% of users will benefit of the 1% of speed improvement.
But this is worse than 99% of users seeing 5% and 1% who are developers seeing 4% in an ideal world.
Often you can only see the real problem with real data (in production), therefore it is very valuable to be able to profile where the data is without changing the system significantly. Having to reboot into a different distro that has profiling enabled means that you may lose the reproduction of a (performance) bug.
Sure, you may be able to reproduce the problem in the lab, but the same logic applies there (you want to run most of your testing with the exact binaries that users will use, not with a substantially different one that has frame pointers).
But adding complexity is not free.
There’s some irony here: deciding to remove the thing that lets you more easily analyse performance problems and implement performance improvements… in order to improve performance. I wonder whether the 1-2% wins gained by enabling them are compensated, across the industry, by the lost potential for performance win discovery. Somehow, I doubt it.
its not just profiling. Omit frame pointers also made a mess of crash reporting and made debugging distro packages more painful