On Wed, 6 Jul 2022 at 15:57, Jeff Law <jeffreyalaw@xxxxxxxxx> wrote: > > > > On 7/6/2022 8:20 AM, Michael Catanzaro wrote: > > On Wed, Jul 6 2022 at 08:06:45 AM -0600, Jeff Law > > <jeffreyalaw@xxxxxxxxx> wrote: > >> If I'm understanding things correctly, the original proposal is trying > >> to make a very special case of profiling work better -- a case that > >> 99.9% of Fedora users do not need or care about. That seems like a > >> particularly bad cost/benefit for this proposal. > > > > But all Fedora users benefit from performance improvements implemented > > as a result of profiling. > Yes, but, IMHO, you need to find another way to do the profiling you > need to get those improvements. Right. Developers already need to rebuild packages locally. The suggestion that developers of fedora packages can't improve those packages without making system-wide profiling work on every fedora users' machines seems like nonsense. Let's say you profile something and find a performance problem. You tweak the code to improve performance. How do you verify if it improves performance? Do you push the change to rawhide, wait for koji and bodhi to do their thing, then re-profile with the new packages from the updates-testing repo? And if that didn't work, push another change to rawhide, wait for koji and bodhi, and re-profile? Of course not, that would be ridiculous. You build locally and profile using your locally built packages. So you're already doing rebuilds, and you're already profiling custom builds anyway. So you can add frame pointers back in to your local builds that are used for profiling. It's not essential for frame pointers to be present in the official koji builds for you to do that. It might be a minor convenience because it reduces the number of system libs that you need to rebuild locally, but it's just a convenience, not a necessity. Maybe we could make it easier to do local mock builds (or copr builds, or koji scratch builds) with changes to RPM_OPT_FLAGS to simplify rebuilding to get frame pointers. But pushing that to every user just so a handful of people don't have a few extra steps is the wrong trade-off. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
