This is a placeholder bug for implementing interruptible frame construction.

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

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.

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.

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

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.

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:

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

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.

Would that also improve incremental loading?

[Tracking Requested - why for this release]: