I tried to compile firefox 3.1 beta2 with PGO enabled(followed the PKGBUILD file here:http://aur.archlinux.org/packages.php?ID=22919) and I tried the sunspider javascript benchmark(http://www2.webkit.org/perf/sunspider-0.9/sunspider.html),on every test the PGO enabled build is about 1% ~ 5% faster then the normal build I think there should be a pgo USE flag so I can easily build a more optimized firefox~ Reproducible: Always
Second that, just thought I'd add this https://developer.mozilla.org/en/Building_with_Profile-Guided_Optimization :)
Hi there~ Is there any progress to this bug report?
would be great! that's why wine + firefox runs faster than native linux
Created attachment 186413 [details, diff] add pgo USE flag
i'm not sure this change is enough. i read you need firstly to compile with it (and the patch does it), then run the binary which is going to generate the profiled trace, then feed another make run with the profiled file. so i'm lacking the run and 2nd make. maybe my comment is totally wrong, but this is what i understood from mozilla guide. ps. i think /usr hardcoded is a problem on some prefixed installations, but it's not my case.
https://developer.mozilla.org/en/Building_with_Profile-Guided_Optimization says that...more or less...i mean this is xulrunner ebuild to be patched...but i'm lacking scripts callback
Well, yes, my patch is not "complete". It does a two-pass build that misses the _interactive_ firefox profiling run in the middle. But emerge cannot do the interactive run inbetween, can it? So things are only estimated. Like the GCC profiledbootstrap build that does this the same way. Another thing I found out: Firefox does a wrong check for C++ exceptions. So Firefox source builds have C** exceptions enabled, unwanted. Check bug 263979.
what you can do i think is just to add a pause and call to firefox binary. emerge would stop until the binary returns (which means firefox surfed the web following your script and ended) this is different because it won't be cmd line only, of course it will need X running and so on. than you can take the profiled file and compile again. at the moment i think that without the run the profile is totally useless.
Problems with PGO support: 1. Linux/Mac PGO is buggy (see upstream bug) 2. Browser requires interaction after initial build for profiling 3. Interaction => bad. Can perhaps be solved by using a script which does not need interaction 4. We build xulrunner/firefox separately, so xulrunner needs PGO support, which means a minimal test browser is needed for profiling (see the Launchpad bug: https://bugs.launchpad.net/xulrunner/+bug/213708) The interaction problem could be solved be running it over xvfb, but I don't know if that's possible. If all else fails, we could ship a sample profile which should offer _some_ improvement.
(In reply to comment #9) > Problems with PGO support: > > 1. Linux/Mac PGO is buggy (see upstream bug) > 2. Browser requires interaction after initial build for profiling > 3. Interaction => bad. Can perhaps be solved by using a script which does not > need interaction > 4. We build xulrunner/firefox separately, so xulrunner needs PGO support, which > means a minimal test browser is needed for profiling (see the Launchpad bug: > https://bugs.launchpad.net/xulrunner/+bug/213708) > > The interaction problem could be solved be running it over xvfb, but I don't > know if that's possible. If all else fails, we could ship a sample profile > which should offer _some_ improvement. > The issue is being worked on upstream already to allow the same script firefox uses to run with xulrunner pgo build. Once that is done the pgo support will be rather easy to impletement. Just have to wait a few more weeks before pgo can be made a reality.
(In reply to comment #10) > (In reply to comment #9) > > Problems with PGO support: > > > > 1. Linux/Mac PGO is buggy (see upstream bug) > > 2. Browser requires interaction after initial build for profiling > > 3. Interaction => bad. Can perhaps be solved by using a script which does not > > need interaction > > 4. We build xulrunner/firefox separately, so xulrunner needs PGO support, which > > means a minimal test browser is needed for profiling (see the Launchpad bug: > > https://bugs.launchpad.net/xulrunner/+bug/213708) > > > > The interaction problem could be solved be running it over xvfb, but I don't > > know if that's possible. If all else fails, we could ship a sample profile > > which should offer _some_ improvement. > > > The issue is being worked on upstream already to allow the same script firefox > uses to run with xulrunner pgo build. Once that is done the pgo support will be > rather easy to impletement. Just have to wait a few more weeks before pgo can > be made a reality. > any progress on this issue now?
Created attachment 201784 [details, diff] net-libs/xulrunner-1.9.1.2-r1 pgo diff Although the profileserver.py script starts, the http server loads and the client initializes, nothing happens and it seems to hang. Anyone knowing more about python/xulrunner may check what is going wrong, please. Hmm, and I missed the python dependency for a pgo build. :)
I think the way to go here is for portage to provide a sample profile. The same way Mozilla does for Windows; MS Windows Firefox is using PGO and obviously Mozilla profiled it against some sample pages, and it still beats Linux Firefox in term of speed by a good margin. Gentoo could do the same, generating the profile data by using the upstream endorsed optimization options. That would be the simplest approach that would work out of the box for the majority of people and be the least headache for the Gentoo Mozilla package maintainers.
(In reply to comment #13) > I think the way to go here is for portage to provide a sample profile. The same > way Mozilla does for Windows; MS Windows Firefox is using PGO and obviously > Mozilla profiled it against some sample pages, and it still beats Linux Firefox > in term of speed by a good margin. Gentoo could do the same, generating the > profile data by using the upstream endorsed optimization options. That would be > the simplest approach that would work out of the box for the majority of people > and be the least headache for the Gentoo Mozilla package maintainers. > Nikos if you want to whip something together I will be more then happy to review and commit it.
The only way for this to work would be to build firefox/xulrunner together again. Tracemonkey support should help with speed issues, current ff-4_beta6 in mozilla overlay is just about as fast as windows builds.
Created attachment 276493 [details] pgo support coming I am working to recombine xulrunner and firefox so we can have pgo builds. Here is the initial work up, this is not gonna work for hardened in current state. You will also need to rip a few files out of the mozilla overlay if your wishing to test. I am aware that DISPLAY is not working which will result in failure, this is just for those who are interested in seeing this all come together finally.
Firefox 5 has entered tree with PGO support.
How? USE=pgo emerge firefox ?
(In reply to comment #17) > Firefox 5 has entered tree with PGO support. excellent work, thank you :)
2 problems remain 1) SANDBOX access denied 2) no libmozjs.so installed.
