Closed Bug 299627 Opened 19 years ago Closed 19 years ago

codesize increase due to rebranding

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: kairo, Unassigned)

Details

brad and luna tinderboxen show a significant codesize (Z) increase with
rebranding, need to look in closer what could cause that. Note that embed
codesize (mZ) is unaffected.

numbers from brad:
Z:23.78MB --> Z:23.83MB
Zdiff:+47744 (+126349/-78605)

numbers from luna:
Z:18.41MB --> Z:18.47MB --> Z:18.45MB
Zdiff:+65184 (+123558/-58374); Zdiff:-17376 (+0/-17376)

note that luna got CTho's installer images one cycle later than the rest of the
rebranding changes.

biesi already did some investigating of the numbers, would be good to add your
findings here.
The change is basically exclusively due to a change in the .nosyms.rodata
symbol. I note that a later luna cycle reduced codesize by around 17 KB (iirc),
which was also in .nosyms.rodata, and the only checkin changed the installer's
logo.xpm.
Those are the interesting changes from brad:

seamonkey-bin
+99013 .nosyms.rodata
+1072 splash_xpm

mozilla-bin
-33701 .nosyms.rodata
-1220 splash_xpm

mozilla-installer-bin
-17408

(note that this log doesn't list a seamonkey-installer-bin)

Now the really interesting thing is what's in .nosyms.rodata?
Here are the numbers from luna, both logs added together (first only has
mozilla-bin/seamonkey-bin, second has mozilla-installer-bin)

seamonkey-bin
+99010 .nosyms.rodata
 +1072 splash_xpm
  
mozilla-bin
-33666 .nosyms.rodata
 -1220 splash_xpm
  
mozilla-installer-bin
Total: -17376 (+0/-17376)

again, no mention of seamonkey-installer-bin

I backed out the new splash screen; let's see what Z effect it has.
luna:
Z:18.39MB
Zdiff:-65184 (+160/-65344)

  seamonkey-bin
  	Total:	     -65184 (+160/-65344)
  	Code:	         +0 (+0/+0)
  	Data:	     -65184 (+160/-65344)
  	       +160 (+160/+0)	data (DATA)
  		       +160 (+160/+0)	UNDEF:seamonkey-bin:data
  			       +148	splash_xpm
  			        +12	.nosyms.data
  	     -65344 (+0/-65344)	rodata (DATA)
  		     -65344 (+0/-65344)	UNDEF:seamonkey-bin:rodata
  			     -65344	.nosyms.rodata

filesize comparison:

old (pre-rebranding) throbber:
-rw-r--r--  1 chb chb 103K  4. Jul 16:43 /tmp/mozilla/xpfe/bootstrap/splash.xpm

rebranded throbber:
-rw-r--r--  1 chb chb 101K  4. Jul 02:21 splash.xpm

The difference is 2219 bytes.
<ajschult> right.  the new splash is 2 pixels narrower and 3 pixels shorter than
the original
<ajschult> 392x263 => 390x260
<biesi> new splash has fewer colors too

All that should lead in the opposite direction of what we are seeing :(
OK, I have an explanation.

The splash screen is an array of lines. In the old splash, a lot of lines were
identical (all orange). In the new one, few lines are identical. I bet the
compiler or linker folded identical string literals and stored them only once;
that can't be done for the new splash.
OK, in this case I'd say, good to know - but we have to ignore it.

We may want to invent a mechanism that uses only an outside file for the splash
(note that we should have a lot of that in place, as we already allow external
splashes). This could increase Ts though, but it should remove the splash from
binary size. Additionally, we want to contribute such a thing to XULRunner one time.

This bug is WONTFIX in my eyes, as soon as the new splash is back in.
Any objections?
(new splash is back in now)
As long as we're using xpm splashes this way, we can't do better, from what we know.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WONTFIX
I was surprised how many "splash screen" bugs existed in bugzilla. 

Bugzilla Bug 27446
Bugzilla Bug 194291
Bugzilla Bug 195577
also: Bugzilla Bug 29775
You need to log in before you can comment on or make changes to this bug.