On Tue, Dec 06, 2022 at 03:12:19AM +0000, Gary Buhrmaster wrote:
Note that is not a fully equivalent scenario. The no-omit-frame-pointer
proposal was only offering a functional debugging benefit to a fairly
small number of users who are also developers, while adding a likely
performance hit to all users. There needs to be a high bar to justify
the performance hit when the benefit offered is narrow.
First, frame pointers are not just for debugging benefit. It's not even it's main
benefit from POV of
https://pagure.io/fesco/issue/2817. Frame pointers are for performance
profiling and observability first and foremost, and that's most useful under
real-world conditions of production workloads. Not some custom re-built debug versions of
applications.
Second, it might benefit a relatively small (but not tiny, it's at least thousands of
people doing performance profiling) fraction of users, but those users (developers that
care about performance) are the ones bringing benefits to very wide user base.
And third, with appropriate infrastructure of background perf profiling that projects like
GNOME and KDE can put in place (if they haven't already), user doesn't have to be
involved in performance profiling directly to benefit the ecosystem at large, providing
anonymized source of real-world profiling data that could be aggregated and looked at by
GNOME/KDE/whatnot developers that do care about performance.
But this won't happen unless GNOME/KDE can rely on having frame pointers in user
systems.
>
> This proposal is adding a functional security benefit to all users,
> alongside the possible performance hit. This is more easily justifiable,
> especially given Fedora's track record of being willing to security
> improvements even when they have a performance hit.
>
> With regards,
> Daniel