On Sat, Feb 14, 2009 at 5:24 PM, Chris Adams <cmadams@xxxxxxxxxx> wrote: > Rather than do it at build time, could the packager(s) not build with > profiling on, run through some set of tests, and then just include the > profiling output in the RPM sources? > > You'd want a build-time option in the spec file to turn profiling on; > you'd run that special build to gather the profiling data, then include > that output in the source RPM for the "real" (non-profiling) build. > That way the build is repeatable, and there's no fiddling with trying to > make interactive programs batch-mode for scripted profiling. > > I don't know how tightly the profiling data and optimization is tied to > a particular build though, so this may not be feasible. Sadly, the profiles are fairly tied to the source code. (This is the same data that gcov uses, so you can look at the gcov manpage for more information) GCC complains loudly if they don't match exactly, and any line number offset will scramble the profiling and likely give worse performance than without profile driven optimization at all. This is quite unfortunate because I like the idea of distributing the profile along with the source since that means the compilation would be more easily reproducible. (and keeping profile generation out of the build system is probably a precondition for this kind of thing ever seeing widespread use) > For JavaScript, it may be possible to build a stand-alone program that > executes JS, and have some canned JS files to feed it for profiling the > JS engine. Possibly, but if profile driven optimization is useful for Firefox's JS support then it's probably worth doing for some (or many) other things. Perhaps it would be possible to create a 'portable profile' format which is symbolically tied to the source function using the function name plus a content hash, so that as the source changed the compiler would gradually stop using it. Perhaps someone with greater experience with GCC's profile driven optimization than I can speak up. -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
