Created attachment 194619 [details] patch to remove -O3 for SET+=OPTIMIZED_CFLAGS (MOZ_OPTIMIZE_FLAGS) Hi, are we sure we want to append -O3 forcibly to CFLAGS for www/firefox? I have found it is just making the application larger compared to the default -O2 set in CFLAGS but not necessarily resulting in any better performance, at least I can't really tell. For my laptop with inadequate RAM, it seems to perform better compiled with -O2 actually, I think. built with -O3: > pkg info firefox | grep size Flat size : 123MiB > ls -lh /usr/local/lib/firefox/{firefox,libxul.so} -rwxr-xr-x 1 root wheel 166K Jun 15 09:38 /usr/local/lib/firefox/firefox -rwxr-xr-x 1 root wheel 67M Jun 15 09:38 /usr/local/lib/firefox/libxul.so built with -O2: > pkg info firefox | grep size Flat size : 121MiB > ls -lh /usr/local/lib/firefox/{firefox,libxul.so} -rwxr-xr-x 1 root wheel 162K Jun 24 15:51 /usr/local/lib/firefox/firefox -rwxr-xr-x 1 root wheel 65M Jun 24 15:51 /usr/local/lib/firefox/libxul.so If anyone has any benchmarks comparing the two optimization levels for www/firefox I would be interested to take a look. (And please indicate Firefox version, arch, cores and memory size where you ran the test.) Taking a quick peek at about:buildconfig on Android and Fedora Linux, they are using -Oz with LLVM/Clang5 and -O2 with GCC7 respectively.
I know this will incite heckling and a tomato thrown at me but I also noted that even the Windows build of firefox uses VC's -O1 (optimize code for minimum size), similar to Android's -Oz optimization in about:buildconfig. I wouldn't advocate for -Oz over -O2, but I am suggesting -O3 is not the most desirable optimization level, particularly for such an already large application like firefox, where a marginal gain in corner cases cannot overcome larger binary size that ultimately slows down overall loading and execution. But again, if anyone has browser benchmarks I would be very interested to study them.
-O3 is enabled by default because Mozilla uses it on macOS which is like FreeBSD a Clang platform. FreeBSD Port allows to override -O3 via CFLAGS in make.conf as only the last -O<n> matters. (In reply to Kenneth Salerno from comment #0) > laptop with inadequate RAM Firefox is supposed to take advantage of mozjemalloc to keep memory usage low. Unfortunately, it hasn't been ported to FreeBSD despite originating from there. If Stylo performance isn't very important try the following workaround: # jemalloc4 tunning before https://bugzilla.mozilla.org/show_bug.cgi?id=1363992 $ MALLOC_CONF="narenas:1,tcache:false" firefox ... > Fedora Linux ... GCC7 Distro builds may use different flags. Try looking at Mozilla build logs from "opt" jobs in https://treeherder.mozilla.org/#/jobs?repo=mozilla-release Another option is to extract a binary: $ fetch https://download.cdn.mozilla.net/pub/firefox/releases/61.0/linux-x86_64/en-US/firefox-61.0.tar.bz2 $ tar xkf firefox-61.0.tar.bz2 $ (cd firefox; tar xUf omni.ja) $ (cd firefox/browser; tar xUf omni.ja) $ fgrep -B2 -- -O3 firefox/chrome/toolkit/content/global/buildconfig.html <td>/builds/worker/workspace/build/src/gcc/bin/g++</td> <td>6.4.0</td> <td>-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wall -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof -Wduplicated-cond -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=coverage-mismatch -Wno-error=free-nonheap-object -Wformat -D_GLIBCXX_USE_CXX11_ABI=0 -fno-sized-deallocation -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pthread -pipe -g -O3 -fomit-frame-pointer</td>
(In reply to Jan Beich from comment #2) > FreeBSD Port allows to override -O3 via CFLAGS in make.conf as only the last -O<n> matters. make.conf is read before Mk/bsd.gecko.mk, so the CFLAGS+=-O3 is ultimately the last parameter and thus forced. The only way around it short of hacking Mk/bsd.gecko.mk is to unset OPTIMIZED_CFLAGS, but then this has the side-effect of passing configure --disable-optimize which adds the flag -fno-omit-frame-pointer which increases function call time if you have no intention of debugging. I'm not sure what a compromise could be unless we introduce another port option (disabled by default to not upset people) to optimize for size? See attached patch.
Created attachment 194687 [details] patch to add new option to www/firefox to optimize for minimum size
Created attachment 194688 [details] patch to add new option to www/firefox to optimize for minimum size removed a script redundancy I had
Created attachment 194689 [details] patch to add new option to www/firefox to optimize for minimum size third time is the charm.
Created attachment 194733 [details] patch to add new option to www/firefox to optimize for minimum size Apparently -Oz makes firefox segfault, switching to -Os. Results on my laptop: virtual mem utilization for firefox went from >1.4G to 500M, improving responsiveness.
ping!
Keyword: patch or patch-ready – in lieu of summary line prefix: [patch] * bulk change for the keyword * summary lines may be edited manually (not in bulk). Keyword descriptions and search interface: <https://bugs.freebsd.org/bugzilla/describekeywords.cgi>
The patch keyword is now deprecated. Should we take this to Phabricator for review?
Comment on attachment 194733 [details] patch to add new option to www/firefox to optimize for minimum size … on closer inspection, this patch no longer applies.