[nrvn]

from Go documentation[0]:

> Committing profiles directly in the source repository is recommended as profiles are an input to the build important for reproducible (and performant!) builds. Storing alongside the source simplifies the build experience as there are no additional steps to get the profile beyond fetching the source.

I very much hope other languages/frameworks can do the same.

[0]: https://go.dev/doc/pgo#building

[nyrikki]

The Performant claim there is counter to research I have heard. Plus as the PGO profile data is non-deterministic in most cases, even when compiled on the same hardware as the end machine "Committing profiles directly in the source repository" is the reason why they are deleted or at least excluded from the comparison.

A quote from the paper that I remember on the subject[1] as these profiles are just about as machine dependent as you can get.

> Unfortunately, most code improvements are not machine independent, and the few that truly are machine independent interact with those that are machine dependent causing phase-ordering problems. Hence, effectively there are no machine-independent code improvements.

There were some differences between various Xeon chip's implementations of the same or neighboring generations that I personally ran into when we tried to copy profiles to avoid the cost of the profile runs that may make me a bit more sensitive to this, but I personally saw huge drops in performance well into the double digits that threw off our regression testing.

IMHO this is exactly why your link suggested the following:

> Your production environment is the best source of representative profiles for your application, as described in Collecting profiles.

That is very different from Fedora using some random or generic profile for x86_64, which may or may not match the end users specific profile.

[1] https://dl.acm.org/doi/10.5555/184716.184723

[clhodapp]

If those differences matter so much for your workloads, treat your different machine types as different different architectures, commit profiling data for all of them and (deterministically) compile individual builds for all of them.

Fedora upstream was never going to do that for you anyway (way too many possible hardware configurations), so you were already going be in the business of setting that up for yourself.