263512 - /opt:nowin98 increases code size

Status: RESOLVED INVALID

(SeaMonkey :: Build Config, defect)

Description

[Brian Ryner (not reading)]

Despite the MSDN documentation's claims that it decreases size, when we started
using /OPT:nowin98 for Firefox builds (MOZ_DEBUG_SYMBOLS=1), code size
increased.  Removing the option takes us back to where we were before.

Comment 1

[Brian Ryner (not reading)]

Attachment: patch

Comment 2

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 161500 [details] [diff] [review]
patch

r+a=[e-mail] yay

Comment 3

[Brian Ryner (not reading)]

checked in trunk and aviary branch, requesting 1.7 branch approval as well.

Comment 4

[cls]

See related bug 54199 & bug 216333 so we're not constantly revisiting the same
issues.  I assume the code measurements were done with VC6SP5 ?

Comment 5

[Doug Wright]

Windows setup file FirefoxSetup.exe grew 3K  from yesterdays build with this
checkin (4811K from 4808K).

I know it's only a very small increase, but this was supposed to decrease size..

Comment 6

[cls]

(In reply to comment #5)
> Windows setup file FirefoxSetup.exe grew 3K  from yesterdays build with this
> checkin (4811K from 4808K).

What checkin?  The only related one I see is bryner's from today to apply the
attached patch.

It seems strange that code that hasn't changed in 2 years would suddenly cause a
3k increase in file size.  And why just remove the /opt:nowin98 from the debug
case?  What about the NS_TRACE_MALLOC & the MOZ_COVERAGE cases?  

Comment 7

[Doug Wright]

Maybe I'm confused....

Comment #0 says that using this option code size grew, and that removing it
should make the code size shrink.

ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2004-10-07-06-0.9/FirefoxSetup.exe
is 4808K

ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2004-10-08-14-0.9/FirefoxSetup.exe
is 4811K (built after bryner checked the patch in).

Comment 8

[cls]

No, I'm the confused one.  I thought you were addressing my questions about code
size measurements but instead you were pointing out that the patch didn't have
the intended effect.

Comment 9

[Bill Gianopoulos [:WG9s]]

The issue is that executables built for win98 should have modules that align on
4kb boundaries.  Otherwise the system has to do alot of moving around of stuff
while loading the progam.  Selecting the /opt:nowin98 says that you are building
an executable that you do not itend to be run on a windows98 platform.  From the
MSDN documentation:

The only time you should not use /OPT:WIN98 is when your portable executable
image is very small. Even if an image is slated for downloads, the wasted space
is zero-filled and compresses well.

So, if we are trying to reduce the size of the download, the impact on size
should be minimal.  The impact on startup time on win98 is probably significant.
 This has more of an impact on the disk space used on the desktop system after
installation than it does on download size.

Building without the /opt:nowin98 is the right thing to do even if it does make
the build 3kb larger.

Comment 10

[Bill Gianopoulos [:WG9s]]

Should have mentioned that my guess is that this option would effect startup
time on Windows/ME as well because it is essentailly a renamed Windows/98. 
Sorry for bugspam.

Comment 11

[Mike Kaply [:mkaply]]

Comment on attachment 161500 [details] [diff] [review]
patch

a=mkaply

Comment 12

[Brian Ryner (not reading)]

Ok, my measurements were flipped (oops!).  The real cause of the size increase I
was looking for was /FIXED:NO (see bug 263680).  For reference, here's what I
see on a firefox static build, VC6SP5 (taking one dll as representative of dlls,
and then the exe):

with /opt:nowin98:
xpcom.dll          378955
firefox.exe        7021645

without /opt:nowin98:
xpcom.dll          393294
firefox.exe        7028816