It seems it may be an issue with a legacy addon, AdBlockPlus

Why are you removing the project? Please don't modify tasks. Can you confirm the speed has improved since disabling the addon?

In T4966#88802, @selfus wrote:

It seems it may be an issue with a legacy addon, AdBlockPlus

FWIW: uBlock Origin is a nice replacement for AdBlockPlus and it's already available as webExtension.

Sorry @Justin , it did it automatically

@kyrios123 I will try adblock first, but thanks for the suggestion

I also found Firefox loading pages slower. Disabling Tab Groups which was the only Legacy addon I had, I noticed the default content process limit went from 1 to 4 under Performance in settings when you disable "use recommended performance settings".
I think this has something to do with Stylo being enabled by default.

@mate-user I agree with you.

I seen an improvement after disabling legacy addons, but the behavior has now returned and some pages are still loading very slowly, I am looking at you gitlab.

I have the same problem of slowing down ; as said mate-user by deactivating servo: firefox has no more worries. under manjaro servo is not active.
"layout.css.servo.enabled to false"

I tried Firefox 57 in a Linux Mint 18.3 beta Mate live USB session and it worked very fast with Stylo/Servo enabled by default.
Hopefully once Firefox 57 is released as a stable update in Solus, this issue will be resolved.

Firefox 57 still seems slow for me on Solus Mate. Setting "layout.css.servo.enabled" to false in about:config seems to load pages faster.

I confirm, without servo firefox 57 goes faster ,with servo some pages do not respond anymore......

For now I've disabled servo and Firefox works much faster. Hopefully Firefox for Solus is updated to disable servo by default.

Yeah I had the same issue and disabling servo fixed it ?

Solus Budgie

Setting "layout.css.servo.enabled" to false in about:config also improved FF 57 speed performance...compared to the default setting of true.

GM

Trying an optimised build here to see if I can get PGO going. If servo turns out to be the main culprit we'll turn it off.

Hey Boss,

Yeah, that servo change helped quite a bit. What I wouldn't say is Chrome-like performance gains, but then again maybe Quantum isn't suppose to be on par with it with their first release of the new engine.

Maybe I'm full of it too, and it should kick -ass. ;)

Like you, I'm seeing 6194 via Peacekeeper.

Thanks for taking a peek!
GM

Also, that Peacekeeper 6194 result is via an i7 Kaby Lake w/12GB...if it's of any help.

GM

Copying across my comment from Reddit:

Repo Firefox

• Browserbench - Arithmetic Mean:92.4 ± 0.94 (1.0%)
• Peacekeeper - 6194

PGO Firefox

• Browserbench - Arithmetic Mean:98.4 ± 1.0 (1.1%)
• Peacekeeper - 7122

PGO Firefox w/o Servo

• Browserbench - Arithmetic Mean:98.2 ± 1.1 (1.2%)
• Peacekeeper - 7291

Final review: PGO/Firefox/No-Servo appears to be the winner here all things considered. Notably sites like theregister + reddit load far fast when clicking through the site without servo, and has shown stability issues in another Solus bug report (unresponsive pages).

As such, I'll now push a new Firefox build with Servo turned off, and PGO enabled. For now, Mozilla Telemetry (optional build config) will not be turned on until I learn from Mozilla that I'm OK to do this.

@GreenMartian would love to see your results after the build goes in if you're up for it :D

Newbie question here:

Isn't Servo supposed to be the "new" stuff introduced for speed improvements in firefox 57?

@Paradoxeuh yes - but sometimes things might be too new :D We can evaluate it again on the next major version

Will surely do. I'll post those results ASAP after downloading your next build updates.

Thanks!
GM

Latest build is here if you're not on unstable =)

sudo eopkg it https://packages.solus-project.com/unstable/f/firefox/firefox-57.0-110-1-x86_64.eopkg

Shit that was fast!

Then I'll do it right away for you then. Hold just a minute please...

Ta :D

Peacekeeper results increased to 6680.

Let me know if you'd like a screenshot of that result uploaded.

Scratch that, here it is anyway ;)

Peacekeeper = 6680

Browserbench =73.8

In contrast, here's my results using FF 57 directly from Mozilla's site.

Peacekeeper = 7369

Browserbench = 86.0

OK so they're still running faster than us. Bugger. Alright I guess it's time to compare about:buildconfig, Cheers :)

My pleasure. Will check in over the next couple days to see if there's a need for any additional build testing...

GM

I wonder if this a linux issue with stylo or if it is the same on windows and mac?

Goddamn thats some diff.

Arithmetic Mean:113 ± 1.3 (1.2%)

Mozilla Build

GCC:

-Wall -Wempty-body -Wignored-qualifiers -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=coverage-mismatch -Wno-error=free-nonheap-object -Wformat -fno-strict-aliasing -ffunction-sections -fdata-sections -fno-math-errno -pthread -pipe

G++:

-Wall -Wc++11-compat -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof -Wc++14-compat -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=coverage-mismatch -Wno-error=free-nonheap-object -Wformat -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pthread -D_GLIBCXX_USE_CXX11_ABI=0 -pipe -g -fprofile-use -fprofile-correction -Wcoverage-mismatch -O3 -fomit-frame-pointer -Werror

Build:

MOZ_AUTOMATION=1 --enable-update-channel=release MOZILLA_OFFICIAL=1 PKG_CONFIG=/builds/worker/workspace/build/src/gtk3/usr/local/bin/pkg-config MOZ_PGO=1 CCACHE=ccache CC=/builds/worker/workspace/build/src/gcc/bin/gcc CXX=/builds/worker/workspace/build/src/gcc/bin/g++ --enable-js-shell RUSTC=/builds/worker/workspace/build/src/rustc/bin/rustc CARGO=/builds/worker/workspace/build/src/rustc/bin/cargo --enable-default-toolkit=cairo-gtk3 --with-mozilla-api-keyfile=/builds/mozilla-desktop-geoloc-api.key --with-google-api-keyfile=/builds/gapi.data LLVM_CONFIG=/builds/worker/workspace/build/src/clang/bin/llvm-config --enable-rust-simd MAKE=/usr/local/bin/gmake --enable-crashreporter --enable-elf-hack --enable-official-branding --enable-stdcxx-compat --enable-verify-mar

Solus Build

GCC:

	-Wall -Wempty-body -Wignored-qualifiers -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=free-nonheap-object -Wformat -Wformat-overflow=2 -mtune=generic -march=x86-64 -g2 -O2 -pipe -fPIC -Wformat -Wformat-security -fno-omit-frame-pointer -fexceptions -D_FORTIFY_SOURCE=2 -fstack-protector --param ssp-buffer-size=32 -fasynchronous-unwind-tables -ftree-vectorize -feliminate-unused-debug-types -Wall -Wno-error -Wp,-D_REENTRANT -fno-delete-null-pointer-checks -fno-lifetime-dse -fno-schedule-insns2 -fno-strict-aliasing -ffunction-sections -fdata-sections -fno-math-errno -pthread -pipe

G++:

-Wall -Wc++11-compat -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof -Wc++14-compat -Wc++1z-compat -Wimplicit-fallthrough -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=free-nonheap-object -Wformat -Wformat-overflow=2 -mtune=generic -march=x86-64 -g2 -O2 -pipe -fPIC -fno-omit-frame-pointer -fexceptions -D_FORTIFY_SOURCE=2 -fstack-protector --param ssp-buffer-size=32 -fasynchronous-unwind-tables -ftree-vectorize -feliminate-unused-debug-types -Wall -Wno-error -Wp,-D_REENTRANT -fno-delete-null-pointer-checks -fno-lifetime-dse -fno-schedule-insns2 -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pthread -pipe -g -fprofile-use -fprofile-correction -Wcoverage-mismatch -O3 -fomit-frame-pointer

Build:

--enable-application=browser --enable-update-channel=release MOZILLA_OFFICIAL=1 CC=x86_64-solus-linux-gcc CXX=x86_64-solus-linux-g++ 'BINDGEN_CFLAGS=-I/usr/include/nspr -I/usr/include/pixman-1' --enable-system-ffi --enable-default-toolkit=cairo-gtk3 MAKE=make --enable-system-hunspell --enable-crashreporter --enable-official-branding --enable-pie --enable-startup-notification --disable-strip --enable-system-pixman --with-system-sqlite --disable-updater --prefix=/usr --with-system-bz2 --with-system-jpeg --with-system-libevent --with-system-libvpx --with-system-zlib

Immediate things of interest:

• Mozilla use --enable-elf-hack & --enable-rust-simd
• We have lots more flags.
• They don't appear to perform any hardening on their build.

Considerations: Allow Firefox to continue to build its own NSS/NSPR, also allow SQLite, enable elf hack and rust SIMD

I found something interesting! After reading this https://hacks.mozilla.org/2017/11/comparing-browser-page-load-time-an-introduction-to-methodology/, I thought I should try Firefox with Ublock Origin disabled and Tracking Protection set to Always, and it looks like most ads are blocked on websites, and the pages load fast as well !
Anyone else see dramatic improvements ?

mate-user,

Tried your suggestion, and I'm seeing Peacekeeper & Browserbench #'s that are approximately even with the testing screenshots that I posted above for the latest FF build release from Solus.

I'm interested the information you provided about uBlock & Tracking Protection, and will definitely try it. If I can eliminate an add-on, that would be great.

ikey,

Thanks for your work on FF57 today.

GM

mate-user,

After disabling uBlock & enabling Tracking protection, I picked up about a one second advantage in cold booting FF. Unfortunately, Tracking protection didn't do much in terms of ad blocking for me on sites that I use often. One example is YouTube. So, I just had to re-enable uBlock. That one second advantage was likely due disabling the ad blocker.

GM

Once we have our core rebuilds in later and our kernels, I'll rebuild the dependent stack for Firefox with our new distro flags and then rebuild Firefox itself. After that it should be absolutely blazing

Gale force winds...blowing into the sails of Solus. ;)

In T4966#91347, @ikey wrote:

Once we have our core rebuilds in later and our kernels, I'll rebuild the dependent stack for Firefox with our new distro flags and then rebuild Firefox itself. After that it should be absolutely blazing

:D

@GreenMartian I also noticed ads still showing on YouTube sometimes so now I've enabled tracking protection to Always and also enabled Ublock Origin.

@ikey Thanks for the quick update and releasing it today! I went to about:config and noticed the servo setting was still there as I had set it, to false. I reset it to default and the value was blank and now when I search, there are no results for servo or stylo! At least nobody can enable servo and try to give Solus a bad name, haha :)

@ikey I think this task here T4966 should be a subtask of T5083. Right now it's the other way around.
And this task can be marked as Resolved, right ?

@mate-user No, it shouldn't be a sub-task, because the build flags need to be addressed first, which means it's a sub-task.

How is Firefox for people now? Do we want this closed or..?

Firefox is definitely fixed for me, i think we can close... ??

I haven't compared with other install but I can tell I feel the difference !

After updating to the latest release, just thought I'd follow up by posting numbers for Browserbench and Peacekeeper.

Looks like my performance of FF 57 has actually regressed since the latest update.

I know this task was closed as resolved, but just wanted to make sure these follow-up results made it to thread. Unsure that opening a new task is what you'd prefer...

I've run each test twice.

In contrast & to be a little different this time, here are results with Firefox "Nightly" (as opposed to FF 57 earlier in this thread) directly from Mozilla...

Update/follow with Firefox 58.0
stylo disabled: http://peacekeeper.futuremark.com/results?key=FVrL&resultId=15178125
stylo enabled: http://peacekeeper.futuremark.com/results?key=FVrE&resultId=15178066

Update with Firefox 59.0
stylo disabled

• Speedometer2.0 test 1: 44.4, test 2: 43.6, test 3 46.7
• Jetstream 133.09 (+/- 2.3042)
• RoboHornet 0141.92

stylo enabled

• Speediometer2.0 test 1: 44.3, test 2: 44.7
• Jetstream 148.72 (+/- 19.341)
• RoboHornet 0133.27

I would say that it should be turned back on but I need to test it a bit more first ?

@kyrios123

Suggestion:

If you didn't already switch to using the performance governor when running those tests, you should probably do so.

I'm not sure you can rely on the behaviour of ondemand when running those benchmarks...

Firefox 59
I did some benchmarks against a local build of firefox with --enable-rust-simd, --enable-elf-hack, --enable-stylo against the official firefox 59 tarball

http://browserbench.org/JetStream/

http://www.robohornet.org/#

http://browserbench.org/Speedometer2.0/

http://browserbench.org/Speedometer/

Yeah, quite a big difference in my opinion ?

With the PGO data workload mostly fixed via Xvfb to run headless tests the scores are about even now. This is firefox 59 not 59.1

http://browserbench.org/JetStream/

http://www.robohornet.org/#

http://browserbench.org/Speedometer2.0/

http://browserbench.org/Speedometer/

Looks very promising !

Some benchmarks of Firefox 62.0 build with GCC 8.2.0 and Clang 6.0.1 both with PGO and LTO disabled.
CPU scaling governors set to performance

Basically the Speedometer2.0 and ARES-6 results are slightly better with the clang build and MotionMark runs faster with the Clang compiled version.

Clang Speedometer2.0

• 01 https://i.imgur.com/Z0Vb6Uj.png 65.9 ± 1.4 (2.2%)
• 02 https://i.imgur.com/BJiqezW.png 66.7 ± 1.1 (1.7%)
• 03 https://i.imgur.com/7GzNhDe.png 66.2 ± 0.69 (1%)

Clang ARES-6

• 01 https://i.imgur.com/n1Q81OG.png 65.40 ± 1.44
• 02 https://i.imgur.com/8Hl2J64.png 65.84 ± 0.99
• 03 https://i.imgur.com/Yd6Gzm5.png 66.40 ± 0.76

Clang MotionMark

• 01 https://i.imgur.com/BwvhXhx.png 152.38 ± 7.07%
• 02 https://i.imgur.com/TeHktSM.png 148.10 ± 6.73%
• 03 https://i.imgur.com/RxQFlAs.png 149.03 ± 6.70%

Clang JetStream

• 01 https://i.imgur.com/s2E0NLI.png 181.35 ± 3.5078
• 02 https://i.imgur.com/lXrazle.png 179.62 ± 2.2229
• 03 https://i.imgur.com/xkaZWos.png 180.40 ± 4.0285

GCC Speedometer2.0

• 01 https://i.imgur.com/buI9yX0.png 64.2 ± 1.4 (2.2%)
• 02 https://i.imgur.com/Wa6Lokd.png 63.5 ± 1.1 (1.7%)
• 03 https://i.imgur.com/rmINlAm.png 64.2 ± 0.75 (1.2%)

GCC ARES-6

• 01 https://i.imgur.com/jBXt09r.png 66.44 ± 1.24
• 02 https://i.imgur.com/YemgIFW.png 66.96 ± 2.19
• 03 https://i.imgur.com/BW0zj4w.png 66.85 ± 0.28

GCC MotionMark

• 01 https://i.imgur.com/EahfON6.png 138.36 ± 6.19%
• 02 https://i.imgur.com/XXPj2Su.png 138.67 ± 6.25%
• 03 https://i.imgur.com/uWIGtm0.png 130.89 ± 7.18%

GCC JetStream

• 01 https://i.imgur.com/eWsGpwF.png 178.63 ± 1.8009
• 02 https://i.imgur.com/B2hAB1P.png 179.20 ± 2.2773
• 03 https://i.imgur.com/Owr3qb3.png 180.33 ± 3.4119

Firefox are building the browser them selves with clang and LTO enabled for the best performance, so it should in theory be the way to go, if possible that is... How are the tests looking with style enabled? Maybe it should be turned back on by now?

Stylo is enabled. It's on by default, no need to explicitly enable it.

Basically the Speedometer2.0 and ARES-6 results are slightly better with the GCC build, MotionMark runs faster with the Clang.

For ARES-6 less is more and for Speedometer2.0 more points is better. That means Clang was faster/neutral in every case (on your machine).

FWIW Mozilla recently switched to Clang and enabled PGO: https://www.phoronix.com/scan.php?page=news_item&px=Firefox-Clang-LTO-All-Platforms

Sorry my bad, thought Stylo was still disabled but like @mati865 say, they recently switched to building with Clang and LTO and PGO on Linux. I think it might be worth doing it here too then.

I think that without PGO or LTO there's not point to switch to Clang.

Thanks @mati865, I have updated my comment.

Regarding Clang/LTO/PGO, as you all, I read the news but the switch is done on the nightly builds. I am facing issues with PGO/LTO on the current version.
Why do you think I suddenly did these benchmarks now 😉

I haven't worded it properly. There is no need to switch to Clang ASAP it's good to prepare ground for it regarding their statement:

The build system will soon choose clang by default on all builds, but won’t enable PGO/LTO.

IMHO Firefox 63 sounds like a good target to build it with Clang and invite more people to test it for regressions.

I am facing issues with PGO/LTO on the current version.

To use LTO, PIE and a few dozens of backports are required which would affect stability.
Definitely it's not worth to go for it just yet, upstream is hoping to get LTO/PGO with Firefox 64 but who knows...

I have enabled PIE with version 57.0.4.
At the moment, I am doing some "experimentation" with firefox 63b5, if D3815 is not yet landed when I finish playing, I'll update it to build with clang as firefox is slightly faster with it and I haven't noticed any regression.

For curious people, I did some benchmarks of Firefox 63b05 build with the same Clang settings as the above Firefox 62.0 build. This time PGO was enabled but I don't think it worked. Enabling LTO still causes the build to fail.

Look for this to know if PGO is not working (firefox is segfaulting when trying to collect profile data)

ExceptionHandler::GenerateDump cloned child 7129
33:42.71 ExceptionHandler::SendContinueSignalToChild sent continue signal to child
33:42.71 ExceptionHandler::WaitForContinueSignal waiting for continue signal...
33:44.41 jarlog: /home/build/YPKG/root/firefox/build/firefox-62.0/obj-x86_64-pc-linux-gnu/jarlog/en-US.log
33:44.41 ExceptionHandler::GenerateDump cloned child 7180
33:44.41 ExceptionHandler::SendContinueSignalToChild sent continue signal to child
33:44.41 ExceptionHandler::WaitForContinueSignal waiting for continue signal...

If PGO is working look for this being spammed half way through the build

28:26.67 (firefox:23361): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
28:26.67 /usr/bin/dbus-launch terminated abnormally without any error message

If you build via ypkg-build instead of via solbuild the PGO build should work.

Thanks @joebonrichie it indeed failed