74820 - Big jump in reflows

Status: VERIFIED FIXED

(Core Graveyard :: Embedding: GTK Widget, defect, P1)

Description

[Curt Patrick (gone)]

On the 29th daily reflow testing indicated a big jump in the number of reflows 
and the number has remained high since.  See 
ftp://ftp.mozilla.org/pub/data/reflows/daily.png.

Perhaps coincidentally, the number of leaks counted jumped up dramatically for 
the same build and has also remained very high.  See 
ftp://ftp.mozilla.org/pub/data/leaks/leaks_results_daily.html.

Comment 1

[Christopher Blizzard (:blizzard)]

Why is this assigned to me?

Comment 2

[Cathleen]

marc or someone in layout land, we need help to take a look at this reflow count 
problem....

Comment 3

[Daniel Bratell]

Would that perhaps be:
http://bonsai.mozilla.org/showcheckins.cgi?&treeid=SeaMonkey&batchid=500


In that case it was a cache landing but very few layout changes. Could the patch
for bug 28220 cause something like this?

Comment 4

[Marc Attinasi]

Taking to investigate...

Comment 5

[Marc Attinasi]

Curt, do you have the detailed reflow logs for this? I am interested in one or
both of the following:

1) the reflow counts per frame type
2) the reflow counts per URL

Basically, total reflow counts don't give us much to focus the search, but if we
know what types of frames have more reflows, or if we know which URLs are
showing the biggest jumps, then that will really help.

Comment 6

[karnaze (gone)]

moving to m0.9

Comment 7

[Alec Flett]

can anyone try backing out my rather minor changes to formatting.css? it just
added a rule with a ".link" selector:
http://lxr.mozilla.org/seamonkey/source/themes/modern/global/formatting.css#173

I don't know enough about testing reflow counts to know how to test this, but I
want to make sure it's not me :)

Comment 8

[Marc Attinasi]

Actually, alec's query has made me wonder just how these tests are run. Using
SeaMonkey or and Embed app? Using which skin? What URL's? Is there a description
of the test suite available? Thanks.

I'm checking my change to nsLineLayout (3.95) to see if that could account for
the dramatic change in reflow counts.

BTW: Rod Spears posted to n.p.m.performance instruction on how to dump reflow
counts for those who want to check their changes for themselves...

Comment 9

[Marc Attinasi]

Detailed data is available at:

 http://ftp.mozilla.org/pub/data/reflows/reflow_results_daily.html

Comment 10

[Tracy Walker [:tracy]]

detailed information is available for each days tests at 
http://ftp.mozilla.org/pub/data/reflows/reflow_results_daily.html
"Entire output from reflow test" is lengthy, but I believe it has the info 
you're looking for

Comment 11

[John Morrison]

This test is only on Linux right? libpr0n was enabled in Linux builds for 
builds of 3/30, the build that show the increase (or specifically it was 
enabled at 03/29/2001 23:05). Just a data point.

Comment 12

[Cathleen]

Just verified with Curt, his automation is only available on Linux right now.  
So, this is the result of reflow on Linux.  Curt built the test automation to 
use rods reflow count tool to get reflow numbers.

cc'ing pav

Comment 13

[Marc Attinasi]

I'm almost positive this is due to something changing with images. I looked at 
the reflow comparison chart and noticed that there are some URLs with very small 
or non-existant reflow count deltas, and some with very large deltas. Examining 
those URLs I noticed that those URLs with large deltas have many images, and 
those with small or 0-deltas have few or no images (there is an exception, 
www.lesechos.fr/index.html, which has many images but a small delta: this needs 
further examination).

The correlation is pretty amazing. At the extreme is the URL 
base/www.w3.org_DOML2Core/ : this page has no images and has a delta of 0 (no 
change in reflow counts). At the other extreme, www.zdnet.com_Gamespot.com/ has 
162 images and the reflow delta is 9954, or a 343% increase.

I'll attach the details for others to examine. I'm still not convinced that this 
extra reflowing is terrible since the load times are not suffering, but I'm not 
convinced that it is benign either.

Can anyone build from the same source with and without libp0rn and see what 
happens to the reflows, if it somewhat mirrors the difference between the 3/29 
and 3/30 builds? Pavlov?

Comment 14

[Marc Attinasi]

Attachment: TEXTFILE: Comparison of 2/29 vs. 3/30 builds: reflow counts compared to number of images

Comment 15

[Marc Attinasi]

Over to pav - he says he has this fixed now.

Comment 16

[Stuart Parmenter]

yup, checked in a fix last night

Comment 17

[Tracy Walker [:tracy]]

verified fixed with embed build 2001-04-17