Firefox performance

Gregory Maxwell gmaxwell at gmail.com
Sun Feb 15 06:36:06 UTC 2009


On Sat, Feb 14, 2009 at 5:24 PM, Chris Adams <cmadams at hiwaay.net> 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.




More information about the fedora-test-list mailing list