I did a quick analysis of the degree to which teleporting shapes today. It's not referenced in IonBuilder at all - only in the CacheIR infrastructure.
I did a quick tour of a number of tp-6 page-loads with an instrumented build - measuring the number of uses of the optimization and the number of prototype object guards.
The distribution of typical hit-counts goes like this:
HITS HITPCT SAVES VOLUME VOLPCT
59 0.00 9 590 0.00
537 0.00 8 4833 0.02
1989 0.01 7 15912 0.07
2507 0.02 10 27577 0.13
24021 0.15 5 144126 0.67
29604 0.18 6 207228 0.96
65166 0.40 4 325830 1.50
261538 1.61 3 1046152 4.83
792086 4.88 2 2376258 10.97
2442486 15.04 1 4884972 22.56
12618471 77.71 0 12618471 58.28
Here HITS is the number of hits in CacheIR of the optimization.
The hits are bucketed by SAVES - the length of the proto-chain list that they "saved" from having to be guarded. (so: 2507 hits of the optimization optimized a case where 10 proto-chain guards were saved).
The "VOLUME" column is just HITS scaled by SAVES - an estimate of the amount of computation saved (per optimization use during execution) for each bucket.
So about 60% of uses of the Teleporting chain optimization save us 0 guards.
About 80% of uses save us 0 or 1 guards.
About 97% of uses save us <= 4 guards.
We have a peak at 5 and a sharp dropoff after that, so 5 seems like a good number for a cut off. <0.25% of the volume of saved guards come from those cases.
Bug 1539467 Comment 1 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I did a quick analysis of the degree to which teleporting shapes today. It's not referenced in IonBuilder at all - only in the CacheIR infrastructure.
I did a quick tour of a number of tp-6 page-loads with an instrumented build - measuring the number of uses of the optimization and the number of prototype object guards.
The distribution of typical hit-counts goes like this:
```
HITS HITPCT SAVES VOLUME VOLPCT
59 0.00 9 590 0.00
537 0.00 8 4833 0.02
1989 0.01 7 15912 0.07
2507 0.02 10 27577 0.13
24021 0.15 5 144126 0.67
29604 0.18 6 207228 0.96
65166 0.40 4 325830 1.50
261538 1.61 3 1046152 4.83
792086 4.88 2 2376258 10.97
2442486 15.04 1 4884972 22.56
12618471 77.71 0 12618471 58.28
```
Here HITS is the number of hits in CacheIR of the optimization.
The hits are bucketed by SAVES - the length of the proto-chain list that they "saved" from having to be guarded. (so: 2507 hits of the optimization optimized a case where 10 proto-chain guards were saved).
The "VOLUME" column is just HITS scaled by SAVES - an estimate of the amount of computation saved (per optimization use during execution) for each bucket.
So about 60% of uses of the Teleporting chain optimization save us 0 guards.
About 80% of uses save us 0 or 1 guards.
About 97% of uses save us <= 4 guards.
We have a peak at 5 and a sharp dropoff after that, so 5 seems like a good number for a cut off. <0.25% of the volume of saved guards come from those cases.
I did a quick analysis of the degree to which teleporting shapes today. It's not referenced in IonBuilder at all - only in the CacheIR infrastructure.
I did a quick tour of a number of tp-6 page-loads with an instrumented build - measuring the number of uses of the optimization and the number of prototype object guards.
The distribution of typical hit-counts goes like this:
```
HITS HITPCT SAVES VOLUME VOLPCT
59 0.00 9 590 0.00
537 0.00 8 4833 0.02
1989 0.01 7 15912 0.07
2507 0.02 10 27577 0.13
24021 0.15 5 144126 0.67
29604 0.18 6 207228 0.96
65166 0.40 4 325830 1.50
261538 1.61 3 1046152 4.83
792086 4.88 2 2376258 10.97
2442486 15.04 1 4884972 22.56
12618471 77.71 0 12618471 58.28
```
Here HITS is the number of hits in CacheIR of the optimization.
The hits are bucketed by SAVES - the length of the proto-chain list that they "saved" from having to be guarded. (so: 2507 hits of the optimization optimized a case where 10 proto-chain guards were saved).
The "VOLUME" column is just HITS scaled by SAVES - an estimate of the amount of computation saved (per optimization use during execution) for each bucket.
So about 60% of uses of the Teleporting chain optimization save us 0 guards.
About 80% of uses save us 0 or 1 guards.
About 97% of uses save us <= 4 guards.
We have a peak at 5 and a sharp dropoff after that, so 5 seems like a good number for a cut off. <2.5% of the volume of saved guards come from those cases, and they cap off at 10. We could also just set a cap of 10 to catch those cases if we really care for them.