108660 - Bloat up following 43220 landing

Status: RESOLVED WORKSFORME

(Core :: CSS Parsing and Computation, defect)

Description

[David Hyatt]

Examining tinderbox, it looks like something strange happened following the 
43220 landing.  Both Linuxes show a large increase in bloat.  This is the worst 
offender.

SelectorMatchesData                         2826668      52.36%

dbaron, can you help out here?  Does this look real to you?

Comment 1

[David Hyatt]

Also, jst got a perf improvement from his form flushing fix that seemed to be 
immediately eaten up by this checkin, but that's harder to verify.  Let's 
concentrate on the bloat in the hopes that that might also flush out the perf 
problem.

Comment 2

[David Hyatt]

cc'ing jrgm, so he can investigate this checkin's effect.

Comment 3

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

The SelectorMatchesData objects are constructed on the stack.  This is phony
bloat, and the problem with the bloat tools that are on all tinderboxes (except
the numbered one on Seamonkey-Ports that's the machine on my desk).

However, this increase probably indicates a sinnificant performance hit.

Comment 4

[Christopher Hoess (gone)]

cc'ing waterson, who just asked about this in n.p.m.performance

Comment 5

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

Probably the best way to fix this is by fixing bug 83836.

Comment 6

[John Morrison]

I've done builds/tests against a trunk build from about 1pm today, where I 
have backed out jst's change and/or pierre's change [on win32]. I can reproduce
jst's change, particularly since it was a no-op for most of the pages, but a 
big change for a certain list (which I already had identified earlier). 
However, with pierre's changes, I can't distinguish them from ~1% noise. 

It may be that there was greater impact (or not) on linux, and the results
listed in the tinderbox logs for btek show a clear difference between each of 
the three successive builds. see attached.

Comment 7

[John Morrison]

Attachment: btek data; comparing builds 1:07, 1:37, 1:22 am 11/06

Comment 8

[Pierre Saslawsky]

Per jrgm's data, it's a WorksForMe on Win32.  If there was a problem on Linux, it 
was fixed, or largely balanced, by the changes from dbaron in the initialization 
of SelectorMatchesData (bug 83836).