83757 - interruptible frame construction

Status: NEW

(Core :: Layout, defect, P4)

Description

[Chris Waterson]

This is a placeholder bug for implementing interruptible frame construction.

Comment 1

[Chris Waterson]

Attachment: patch to collect stats on frame construction

Comment 2

[Chris Waterson]

Frame construction times collected on 750MHz machine, running iBench.

Frame Constructor count=5029, minimum=0, maximum=460, mean=10.15+/-37.29
  0: 4221
  10: 252
  20: 55
  30: 134
  40: 43
  50: 22
  60: 56
  70: 32
  80: 18
  90: 9
  100: 8
  110: 34
  120: 26
  130: 16
  140: 5
  150: 8
  160: 12
  170: 4
  180: 9
  190: 12
  200: 1
  210: 1
  220: 8
  240: 1
  250: 5
  260: 2
  270: 1
  280: 9
  290: 16
  300: 5
  310: 1
  350: 1
  360: 1
  460: 1

Comment 3

[Chris Waterson]

Attachment: scatter plot, frames constructed vs. time

Comment 4

[Chris Waterson]

So I collected the above data, plotting frames constructed vs. time using a
patch I'll attach in a second. The data was collected on a 750MHz laptop running
Win2K against iBench. The idea is to try to figure out whether frame
construction time is fairly linear in the number of frames, in which case doing
something simple like doing the recursion in an interruptible |while| loop
instead of the C runtime stack should work well.

Comment 5

[Chris Waterson]

Attachment: patch to collect scatter data

Comment 6

[Chris Waterson]

Note that we don't exactly count the number of frames created; instead, we count
the number of frame-creating calls to ConstructFrameInternal(). This is probably
a better number, as it'd be the most natural point at which to ``flatten'' the
runtime stack recursion.

Comment 7

[Chris Waterson]

Attachment: scatter plot, frames constructed vs. time; 200MHz WinNT iBench

Comment 8

[Chris Waterson]

Attachment: scatter plot, frames constructed vs. time; 200MHz WinNT iBench

Comment 9

[Chris Waterson]

Urgh. Can't keep my axes straight. Here's the histogram of the frame 
construction times, collected on a 200MHz WinNT box against iBench:

Frame Constructor count=4336, minimum=0, maximum=2850, mean=59.79+/-181.73
  0: 2344
  10: 717
  20: 261
  30: 86
  40: 50
  50: 49
  60: 101
  70: 67
  80: 88
  90: 21
  100: 20
  110: 5
  120: 13
  130: 16
  140: 56
  150: 62
  160: 21
  170: 18
  180: 9
  190: 5
  200: 3
  220: 1
  230: 2
  240: 9
  250: 7
  260: 20
  270: 17
  280: 14
  290: 6
  300: 7
  310: 16
  320: 9
  330: 6
  340: 3
  350: 10
  360: 4
  370: 4
  380: 1
  390: 1
  400: 10
  410: 2
  420: 3
  430: 1
  440: 1
  460: 3
  470: 5
  480: 5
  490: 2
  500: 13
  510: 2
  520: 9
  530: 5
  540: 3
  550: 2
  560: 5
  570: 2
  580: 8
  590: 4
  610: 1
  670: 1
  680: 5
  690: 7
  700: 2
  720: 6
  730: 4
  740: 1
  750: 1
  790: 1
  820: 3
  830: 2
  840: 3
  850: 1
  860: 1
  870: 4
  890: 1
  910: 1
  920: 3
  930: 8
  940: 2
  1020: 1
  1160: 3
  1170: 2
  1190: 1
  1200: 1
  1210: 1
  1220: 2
  1230: 6
  1240: 4
  1250: 3
  1260: 3
  1270: 5
  1280: 2
  1420: 1
  1430: 1
  1450: 3
  1460: 2
  1560: 1
  2180: 1
  2850: 1

Comment 10

[Chris Waterson]

I should also note that the 750MHz histogram and scatter plot do _not_ 
correspond to the same run (obviously). The 200MHz histogram and scatter plot 
_do_ correspond to data collected in the same run.

Comment 11

[Chris Waterson]

Okay, I did another iBench run on the 750MHz machine that has this histogram:

Frame Constructor count=2965, minimum=0, maximum=390, mean=14.14+/-39.87
  0: 2220
  10: 214
  20: 122
  30: 82
  40: 22
  50: 69
  60: 35
  70: 12
  80: 9
  90: 35
  100: 34
  110: 5
  120: 10
  130: 14
  140: 7
  150: 19
  160: 5
  180: 6
  190: 2
  210: 1
  220: 6
  230: 2
  240: 7
  250: 22
  260: 2
  300: 2
  390: 1

...and this scatter plot:

Comment 12

[Chris Waterson]

Attachment: scatter plot, frame constructed vs. time; 750MHz WinNT iBench

Comment 13

[Chris Waterson]

Aw for cryin' out loud. Let's try that again.

Comment 14

[Chris Waterson]

Attachment: scatter plot, frame constructed vs. time; 750MHz WinNT iBench

Comment 15

[Chris Waterson]

So if you compare the 200MHz data,

 <http://bugzilla.mozilla.org/showattachment.cgi?attach_id=36903>

and the 750MHz data,

 <http://bugzilla.mozilla.org/showattachment.cgi?attach_id=36905>

It looks pretty similar in shape, and it looks like common sense applies: more 
frames means more time. Specifically, there are no outliers in the upper left-
hand corner of the graph (really long time to construct few frames) that'd make 
a simple approach to interruption break.

I'll tinker around with that to see how hard it looks.

Comment 16

[Markus Hübner]

Would that also improve incremental loading?

Comment 18

[Kan-Ru Chen [:kanru] (UTC+9)]

[Tracking Requested - why for this release]:

Comment 19

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:dholbert, could you have a look please?
For more information, please visit auto_nag documentation.