Open
Bug 83757
Opened 24 years ago
Updated 2 years ago
interruptible frame construction
Categories
(Core :: Layout, defect, P4)
Core
Layout
Tracking
()
People
(Reporter: waterson, Unassigned)
References
Details
(Keywords: perf)
Attachments
(7 files)
This is a placeholder bug for implementing interruptible frame construction.
Reporter | ||
Updated•24 years ago
|
Reporter | ||
Comment 1•24 years ago
|
||
Reporter | ||
Comment 2•24 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
Reporter | ||
Comment 3•24 years ago
|
||
Reporter | ||
Comment 4•24 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.
Reporter | ||
Comment 5•24 years ago
|
||
Reporter | ||
Comment 6•24 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.
Reporter | ||
Comment 7•24 years ago
|
||
Reporter | ||
Comment 8•24 years ago
|
||
Reporter | ||
Comment 9•24 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
Reporter | ||
Comment 10•24 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.
Reporter | ||
Comment 11•24 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:
Reporter | ||
Comment 12•24 years ago
|
||
Reporter | ||
Comment 14•24 years ago
|
||
Reporter | ||
Comment 15•24 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.
Updated•15 years ago
|
QA Contact: chrispetersen → layout
Comment 18•9 years ago
|
||
[Tracking Requested - why for this release]:
Blocks: B2G-Multicore
tracking-b2g:
--- → backlog
Comment 19•2 years ago
|
||
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.
Assignee: waterson → nobody
Status: ASSIGNED → NEW
Flags: needinfo?(dholbert)
Updated•2 years ago
|
Flags: needinfo?(dholbert)
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•