interruptible frame construction

ASSIGNED
Assigned to

Status

()

Core
Layout
P4
normal
ASSIGNED
17 years ago
3 years ago

People

(Reporter: Chris Waterson, Assigned: Chris Waterson)

Tracking

(Blocks: 2 bugs, {perf})

Trunk
Future
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(tracking-b2g:backlog)

Details

Attachments

(7 attachments)

(Assignee)

Description

17 years ago
This is a placeholder bug for implementing interruptible frame construction.
(Assignee)

Updated

17 years ago
Status: NEW → ASSIGNED
Keywords: perf
Priority: -- → P4
Target Milestone: --- → Future
(Assignee)

Comment 1

17 years ago
Created attachment 36890 [details] [diff] [review]
patch to collect stats on frame construction
(Assignee)

Comment 2

17 years ago
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
Depends on: 83737
(Assignee)

Comment 3

17 years ago
Created attachment 36898 [details]
scatter plot, frames constructed vs. time
(Assignee)

Comment 4

17 years ago
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.
(Assignee)

Comment 5

17 years ago
Created attachment 36899 [details] [diff] [review]
patch to collect scatter data
(Assignee)

Comment 6

17 years ago
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.
(Assignee)

Comment 7

17 years ago
Created attachment 36902 [details]
scatter plot, frames constructed vs. time; 200MHz WinNT iBench
(Assignee)

Comment 8

17 years ago
Created attachment 36903 [details]
scatter plot, frames constructed vs. time; 200MHz WinNT iBench
(Assignee)

Comment 9

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


(Assignee)

Comment 10

17 years ago
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.
(Assignee)

Comment 11

17 years ago
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:
(Assignee)

Comment 12

17 years ago
Created attachment 36904 [details]
scatter plot, frame constructed vs. time; 750MHz WinNT iBench
(Assignee)

Comment 13

17 years ago
Aw for cryin' out loud. Let's try that again.
(Assignee)

Comment 14

17 years ago
Created attachment 36905 [details]
scatter plot, frame constructed vs. time; 750MHz WinNT iBench
(Assignee)

Comment 15

17 years ago
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.
(Assignee)

Updated

16 years ago
Blocks: 71668

Updated

16 years ago
Keywords: patch

Comment 16

15 years ago
Would that also improve incremental loading?
QA Contact: chrispetersen → layout
Blocks: 1053946
Duplicate of this bug: 1165544
[Tracking Requested - why for this release]:
Blocks: 1093564
tracking-b2g: --- → backlog
You need to log in before you can comment on or make changes to this bug.