Windows gmake builds currently use -O1 as their default opt level, changing it to -O2 results in a nice perf boost.

Reassigning to Asa as this falls into the almost exact category as bug 53486.

I'm running a -O2 build for months now without *any* problem I'm not sure it's way faster than -O1 (this is very subjective) 5% - 10% would be great Anyway the code is 10-20% bigger and I don't think every piece of moz needs O2 For instance I don't think the installer needs it, etc...

I defer to cathleen on this. I'm not willing to take that much code bloat for that kind of performance gain, but i'm not in charge here :)

Suprise ! I've built RC3 with O2 and VC7 and summed the size of dll and exe I found in both RC3 released by mozilla.org (-O1) and my -O2 build: mozilla release (-O1) : 14009856 my -O2 build : 14642688 so the result is that a -O2 build only adds 4.5 % to the code (and not 10-20 % as I originally thought) some performance numbers are needed (pageload, mail, preference window, ...) to draw a final conclusion but I think that mozilla.org might want to consider shipping a -O2 build :-) note that I used VC7 (with patch attached to bug 127985 where I replaced -Os (small code) by -Ot (fast code) which is exactly -O2)

without some perf numbers this isn't going anywhere.

Here's the window open results I'm seeing with a -O1 & -O2 build: -O1 openingTime=1512,1322,1552,1352,1372,1362,1362,1362,1392 avgOpenTime=1399 minOpenTime=1322 maxOpenTime=1552 medOpenTime=1362 _xulWinOpenTime=1362 -O2 openingTime=1442,1302,1473,1312,1332,1322,1322,1332,1322 avgOpenTime=1351 minOpenTime=1302 maxOpenTime=1473 medOpenTime=1322 _xulWinOpenTime=1322

Thanks for getting these numbers. Unfortunately, not an inspiring tradeoff: 3% faster window open for >2MB of disk dll size increase (of which some proportion would be RSS). Although, as noted, not every module should be -O2 optimized (but we don't currently have a way to do per-module optimization).

Actually, per module optimization can be achieved by setting MODULE_OPTIMIZE_FLAGS in *each* makefile for a particular module. See http://lxr.mozilla.org/seamonkey/source/config/mkdepend/Makefile.in#34 . If no specific optimization flag is passed into configure, MODULE_OPTIMIZE_FLAGS will be used. There's no equivalent configure flag.

I've updated my build to use GNU make and I've made some tests, O1 vs O2, VC6 vs VC7. Here are the results: I can confirm that O2 adds some bloat (+5%, +16%) footprint: +16% disk , +5% memory (VC6 O2) -10% disk , -2% memory (VC7 O1) Memory footprint is more important to me than disk footprint, and the good news is that disk footprint does not totally translate into memory footprint. VC7 does a better job than VC6. anyway O1 wins, especially with VC7 speed: O2 wins but not by much, maybe some page loader test would be more informative anyway 5% is what you can expect so ... | | | |__xulWinOpenTime (ms) | binaries size (bytes) | memory usage (KB) ===========|=======================|=========================|=====================| VC7 O1 | 344 (+ 0%) | 14046208 (- 10%) | 16820 (- 2%) ===========|=======================|=========================|=====================| VC7 O2 | 328 (- 5%) | 16316416 (+ 5%) | 17688 (+ 3%) ===========|=======================|=========================|=====================| VC7 O2 GL | 328 (- 5%) | 16520192 (+ 6%) | 17644 (+ 3%) ===========|=======================|=========================|=====================| VC6 O1 | 344 (*) | 15560704 (*) | 17120 (*) ===========|=======================|=========================|=====================| VC6 O2 | 328 (-5%) | 18071552 (+ 16%) | 17964 (+ 5%) ===========|=======================|=========================|=====================| (*) Mozilla is currently built using VC6 O1, this is the reference Test: ========================================================== Mozilla trunk sources 20020730 build Mozilla with --enable-optimize = "-O1", "-O2" or "-O2 -GL", --enable-extensions=all and MOZ_OFFICIAL=1 go to obj-dir\ and run "make rebase" (rebasing DLLs) New window with no sidebar go to file:///C:/mozsrc/mozilla/xpfe/test/winopen.xul wait the end of the test and note the results Memory usage is indicated by windows task manager, just after the startup (blank window, no sidebar) Machine: ================================== AMD 1800+ 512 MB RAM 40 GB Disk Windows 2000 Server SP2 SRP1

at this point, and after Comment 10, I think that "critical" components should be built with -O2 Why only nspr, nss, and ldap directory are built with -O2 by default in current nightly builds ? Some other components could benefit from this also (at a cost of a minimum overall footprint): string, js (-O2 is used by js.mak !) , dom, expat, htmplparser, libpr0n, mng, png, jpeg, mork, etc... (components that make use of CPU and no I/O ?) The goal could be to get 2%-3% perf at a cost of 2%-3% footprint

> Why only nspr, nss, and ldap directory are built with -O2 by default in current > nightly builds ? Those modules are standmodule modules which are also used outside of the mozilla brower code base. Apparently their owners have already evaluated the size/performance tradeoff and decided that -O2 was worth the tradeoff. For the other modules, someone has to provide the -O1 vs -O2 numbers and the owner has to decide if it's worth the tradeoff.

I've got a number of candidates for -O2 based on data collected by David Baron: http://www.people.fas.harvard.edu/~dbaron/mozilla/jrgm-profile-index This is old data (11-2001) but I think this is still valuable

2 sets: 1 has is the best tradeoff ?

Let's try with these first

Although I was cced a long time ago, I forgot about this bug. When I started doing Win builds myself, I ran into bug 137478. What's worse, I didn't see the bug on any of my machines, so I only knew about it by reports from my customer and users. Could somebody please make a noticable warning in the Windows build instructions (incl. those for 1.0/nmake) that -O2 produces crashes on some systems? Thanks.

There was some good discussion in bug 162096 that talked about using a kind of meta option for the modules. This would determine whether to optimize for speed or size, without specifying a platform specific optimization mode. For instance gcc could use -O3, while windows MSVC builds could use -O2. (Not that I'm suggesting the use of -O3, just citing it as an example). Doing this for specific modules where the gain is worth the price would seem like an easy way to get a perf boost. But then I don't know what's all involved in supporting such a build option ;-)

Filed bug 219356 about letting configure bail on invalid compiler options.

Sorry to spam this bug, but -O2 is working without problem using MS VC++ .Net 2003

I bet Rob cares about this bug, although maybe not its initial premise. I'm sure there are some parts of our code where O2 might be nice though.

A new bug with real perf data would be nice... let's let this one rest in peace.

With the testservers it should be fairly easy to test if -O2 would be faster, and still compliant with all tests...

Pale Moon reports a 25% speedup: http://lifehacker.com/5516964/pale-moon-is-a-faster-firefox-clone-for-windows

Pale Moon is a completely different project, that has nothing to do with this bug. (This bug doesn't even make sense anymore, because we compile all of our releases with PGO.)