Big jump in reflows

VERIFIED FIXED in mozilla0.9

Status

P1
normal
VERIFIED FIXED
18 years ago
7 years ago

People

(Reporter: curt, Assigned: pavlov)

Tracking

Trunk
mozilla0.9
x86
Linux

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
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.
Why is this assigned to me?

Comment 2

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

Comment 3

18 years ago
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

18 years ago
Taking to investigate...
Assignee: blizzard → attinasi

Comment 5

18 years ago
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.
Status: NEW → ASSIGNED

Comment 6

18 years ago
moving to m0.9
Target Milestone: --- → mozilla0.9

Comment 7

18 years ago
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

18 years ago
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...
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

18 years ago
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

18 years ago
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

18 years ago
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?
Priority: -- → P1

Comment 14

18 years ago
Created attachment 29913 [details]
TEXTFILE: Comparison of 2/29 vs. 3/30 builds: reflow counts compared to number of images

Comment 15

18 years ago
Over to pav - he says he has this fixed now.
Assignee: attinasi → pavlov
Status: ASSIGNED → NEW
(Assignee)

Comment 16

18 years ago
yup, checked in a fix last night
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
verified fixed with embed build 2001-04-17
Status: RESOLVED → VERIFIED
Component: Embedding: GTK Widget → Embedding: GTK Widget
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.