82669 - good deal of bloat introduced in 5/21-5/22 checkins

Status: RESOLVED INVALID

(SeaMonkey :: General, defect)

Description

[chris hofmann]

see the graphs.  need hook folks for that day to look at checkins

Comment 1

[chris hofmann]

Attachment: picture of startup bloat diffs from daily tests

Comment 2

[chris hofmann]

bonsai checkin log at:
http://bonsai.mozilla.org/showcheckins.cgi?&treeid=SeaMonkey&batchid=540

Comment 3

[chris hofmann]

adding some hook folks to cc

Comment 4

[Judson Valeski]

I've combed my checkins. nothing suspicious.

Comment 5

[Chris Waterson]

Someone want to try before/after tests using the live bloat stuff? (See
http://www.mozilla.org/projects/footprint/live-bloat.html) This should give us
object and memory counts of heap objects. I can do this Tuesday if nobody else
can get to it...

Also, have we verified that it's not a code increase? (e.g., did we switch
compilers? add a new module?)

Comment 6

[kill this account]

I'm assuming the bloat is Win32.
Both changes I made were in X font code and neither alloc'd memory.

Comment 7

[chris hofmann]

these tests are run on the linux build

Comment 8

[chris hofmann]

have other folks looked at their code?

Comment 9

[Chris Waterson]

Taking from chofmann. I'll do analysis tomorrow.

Comment 10

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

From the graphs doesn't it look like it's mostly a code increase?  (Loading
another module?  Are the tests always run on a blank profile?)

Comment 11

[Chris Waterson]

Here's what trace-malloc says when comparing startup of gtkEmbed. It looks like
the malloc heap is about the same. I'll look at the loaded code next.

                        ---- Base ----   ---- Incr ----   ----- Difference ----
Type                    Count    Bytes   Count    Bytes   Count    Bytes %Total
TOTAL                   44403  2942730   44473  2947105      70     4375 100.00
unclassified-string      2924    87672    2963    90971      39     3299  75.41
dl-unclassified           507    64191     460    65784     -47     1593  36.41
nsPref                   1522    29776    1564    30364      42      588  13.44
nsLocalFile               217    16864     217    17410       0      546  12.48
nsPersistentProperties    750    23846     759    24140       9      294   6.72
nsCategoryManager         176     4412     182     4608       6      196   4.48
nsCStringKey             1195    45380    1199    45558       4      178   4.07
nsAuthURLParser           121     1336     121     1466       0      130   2.97
nsString                   50     1368      55     1488       5      120   2.74
JSRuntime                   9     9180       9     9296       0      116   2.65
nsFontGTK                  46    21700      46    21800       0      100   2.29
nsZipArchive             2014    88321    2016    88417       2       96   2.19
PRLock                    103     8652     104     8736       1       84   1.92
nsRDFResource             294     8881     296     8946       2       65   1.49
gtk-unclassified         1300   148528    1300   148592       0       64   1.46
nsServiceManagerImpl      219     5136     222     5192       3       56   1.28
nsCSSUserInterface        139     7784     140     7840       1       56   1.28
nsSupportsArray           208    12944     209    12984       1       40   0.91
nsGenericModule           322    12508     324    12548       2       40   0.91
OTHER                   32287  2344251   32287  2340965       0    -3286 -75.11

Comment 12

[Chris Waterson]

Here is what /proc/$PID/status shows (granted, on debug builds):

         2001-05-21  2001-05-30
VmSize:	   37692       38176
VmLck:	       0           0
VmRSS:	   28208       29656
VmData:	    7856        6976
VmStk:	      88          88
VmExe:	      80          80
VmLib:	   27924       29124

In other words, between 05-21 and 05-30, VmData dropped by about 880KB, and
VmLib grew by about 1.2MB, for a net growth of 484KB.

I was a bit skeptical that VmData would've dropped so dramatically, so I ran
this a few more times. It looks like VmData fluctuates by as much as 1MB either
way (just starting gtkEmbed to its default home page!) It even fluctuates wildly
when loading ``about:blank''.

That said, the VmLib stays constant, so I think what we want to chase here (as
dbaron intuited) is the change in code size.

Comment 13

[Chris Waterson]

Okay, I'm such a fool. After fiddling around with all my fancy tools for a few
hours, I realized that I'd sent myself on a snipe hunt. Looking at the graph,
_of course_ it's the code bloat. So, I downloaded the two nightlies, ran each,
and diff'd /proc/$PID/maps.

ftp://ftp.mozilla.org/pub/mozilla/nightly/2001-05-21-09-trunk/embed-gcc295-i686-pc-linux-gnu.tar.gz
ftp://ftp.mozilla.org/pub/mozilla/nightly/2001-05-22-09-trunk/embed-gcc295-i686-pc-linux-gnu.tar.gz

2001-05-22 contains several .so files that weren't in 2001-05-21 that, AFAIK,
are necessary for an embedded build. These are:

                Size (bytes)
libeditor.so          741376
libimgjpeg.so          12288
libimgpng.so           86016
libmozbrwser.so        24576
libmozjpeg.so          65536
libnecko2.so           86016
libnsappshell.so      114688
libnsgif.so            12288
libnsjpg.so            12288
libnspng.so            86016
libpipnss.so          815104
libpippki.so           36864
libprofile.so          77824
libtxtsvc.so           49152
libucvlatin.so        159744

I'm going to resolve this as invalid. If there are any _obvious_ .so files that
we can _not_ ship, I don't see them. We know that slacker Pavlov needs to finish
removing imglib1 (which includes some of the .so files above).