Bug 1564017 uses thresholds of 10 and 50 for Baseline Interpreter and JIT respectively. I wanted to use safe values for initial landing, but we can likely increase the JIT threshold more.

Denis is helping us tune this on the reference hardware.

Detailed page load performance measurements from Denis indicate this should be okay
on the reference hardware and now we have 10/100/1000 warm-up thresholds so there's
a nice pattern there.

(In reply to Jan de Mooij [:jandem] from comment #1)

… now we have 10/100/1000 warm-up thresholds so there's
a nice pattern there.

My gut feeling is that a nice pattern with threshold likely indicate a human bias.

Can we get compilation times and speed-up associated with each tier.
At least to verify that the theory matches with the practice.

(In reply to Nicolas B. Pierron [:nbp] from comment #2)

I'll only be able to get this information once bug 1565788 is resolved. I agree that 100 seems oddly coincidental, but I think we could probably revisit the 10/1000 numbers as well, although we'll probably need a different benchmark for Ion as I don't see it impacting page load much now. For the measurements, I chose various numbers ranging from 30->500 across a handful of news sites to exercise JS a bit more. 75 & 100 seemed to be consistently better thresholds than the rest by about 2-3%. That being said, the differences were quite minor across the entire range so for page load I think baseline has much less impact now than it had before.

https://hg.mozilla.org/mozilla-central/rev/1269a661dd65

== Change summary for alert #22206 (as of Wed, 31 Jul 2019 10:23:49 GMT) ==

Improvements:

4% raptor-tp6m-google-maps-geckoview-cold fcp android-hw-g5-7-0-arm7-api-16 pgo 1,124.75 -> 1,075.67
4% raptor-tp6m-google-maps-geckoview-cold fcp android-hw-g5-7-0-arm7-api-16 pgo 1,126.83 -> 1,082.08
4% raptor-tp6m-google-maps-geckoview-cold android-hw-g5-7-0-arm7-api-16 pgo 1,164.44 -> 1,122.66

For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=22206