Interesting: Ubuntu 24.04 LTS will enable frame pointers by default, following Fedora which made the same change in version 38. In short: GCC will by default start emitting frame pointers again as if using -fno-omit-frame-pointer, which helps debugging and profiling tools a bit, at the cost of what they suggest is a generally minimal performance impact.

Frame pointers and why they matter for performance tuning summarizes the history of frame pointers very well, and reveals that this change both in Fedora and Ubuntu actually started by large tech companies like Google, Meta, and Netflix re-building the Linux distributions they run on their servers with ones where frame pointers are enabled.

The Ubuntu announcement is way too long for the information it conveys, but here is the important part:

[…] beginning with Ubuntu 24.04 LTS, GCC will enable frame pointers by default for 64-bit platforms. All packages in Ubuntu, with very few exceptions, will be rebuilt with frame pointers enabled, making them easier to profile and subsequently optimise.

…

There is a small performance penalty associated with the change, but in cases where the impact is high (such as the Python interpreter), we’ll continue to omit frame pointers until this is addressed. Our analysis suggests that the penalty on 64-bit architectures is between 1-2% in most cases. We will not make this change on 32-bit architectures where the penalty is higher.

…

By enabling frame pointers by default, we’re lowering the barrier to entry for performance profiling and debugging, meaning:

  • Simplified Profiling: […] profiling without worrying about compiler configurations.
  • Lower Overhead: Unwinding with frame pointers is significantly cheaper than using DWARF or DWARF-derived information.
  • Debugging Accessibility: […] it will allow bcc-tools, bpftrace, perf and other such tooling to work out of the box.

The announcement does not attempt to explain what frame pointers are or why they are omitted by default, but there are plenty of good sources for this online, for example this answer on Stack Overflow. In short, frame pointers make it easier and faster to figure out at runtime what the current call stack is (without having to consult debug info metadata), at the cost of losing one general-purpose register (rbp). Some more details can be found e.g. here: Trying to understand gcc option -fomit-frame-pointer.

The performance penalty of this seems to be a bit debated: the previous Stack Overflow answer mentions a geometric average of 14% slowdown, whereas the Ubuntu announcement mentions a 1-2% penalty, notably with the exception of Python 3.11, where it is 9.5%. I recommend reading the linked investigation to the Python performance regression as it is very interesting, but in summary it turns out that there are cases where having one more general-purpose register makes a large difference:

In summary, to put it bluntly, there is just more work to do for CPU saving/restoring state to/from stack. But I don’t think _PyEval_EvalFrameDefault example is typical of how application code is written, nor is it, generally speaking, a good idea to do so much within single gigantic function. So I believe it’s more of an outlier than a typical case.

Digging a bit further into the benefits of having frame pointers, as it is pointed out by a HN commenter perf currently relies on frame pointers to do its job without absolutely murdering the performance of the application being profiled, though there are long-term plans to alleviate the need of this with SFrame: fast, low-overhead stack traces.

I personally am not really convinced of the benefits of re-enabling frame pointers – at least on x86-64 – but I do understand that different companies have different priorities and requirements. Still, it looks to me that performing a backtrace should be rather infrequent outside of development and testing, so paying a performance penalty does not seem worthwhile overall, even if it is just 1%. We as software developers should be more mindful of the small ways in which we keep inflating hardware requirements, which essentially forces people to buy new phones and computers were more often than is healthy or sane.