Anyway, the effort that
went into that change proposal has established new expectations for any change that will
impact system performance: the new flags should be benchmarked in an environment where
all
Fedora packages have been rebuilt with the new flags, so we can critique the change
based
on benchmarks that are not representative of real-world usage and reject it if they show
a
2% performance hit, regardless of value to Fedora. If you don't like the idea of
rebuilding all packages with the new flags, then maybe it was a mistake to require
developers to do just that if they want to profile applications successfully.
So I was quite upset when I wrote the above mail, seeing a new change proposal that admits
it adds register pressure a few days after the frame pointer proposal was rejected for
adding register pressure. Probably I should not send mails when angry. I don't
actually support requiring the proposal authors to do the above work. `_FORTIFY_SOURCE=3`
seems certain to make Fedora users safer. Regardless of what happened to the frame pointer
proposal, it wouldn't make sense to block it from benefiting Fedora users. If we were
politicians, then it would totally make sense to block Other Team's proposal unless
Our Team's proposal gets accepted. (I support Team Frame Pointer. ;) But Fedora change
proposals should not operate that way. (We all support Team Fedora here, after all.) This
should go through.
One more note regarding frame pointers. The `_FORTIFY_SOURCE=3` change proposal says
"Per-application performance benchmarks may be useful in understanding the impact for
those specific use cases." But this is not useful at all without an actionable way to
figure out where performance problems are occurring, which requires functional profiling
tools, which require frame pointers. Thank you _very much_ Neal, Fabio, and Zbigniew for
your efforts to revisit that decision.