Closed Bug 299627 Opened 20 years ago Closed 20 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: 20 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.