search for: 40m40s

...ut with high > parallelism (at both FE/client side and backend). > > a) Single profile without profile merging : ~60m > b) Profile merging enabled: > b.1) pool size == 1: ~80m > b.2) pool size == 2: ~47m > b.3) pool size == 3: ~43m > b.4) pool size == 4: ~40m40s > b.5) pool size == 5: ~38m50s > b.6) pool size == 10: ~36m48s > b.7) pool size == 32: ~36m24s > c) >3000 profile file without profile merging (%p): ~35m24s > > b.6), b.7) and c) have the best performance among all. > > Unlike in HDD case, a) has poor perform...

On Sat, Feb 27, 2016 at 6:50 PM, Sean Silva <chisophugis at gmail.com> wrote: > I have thought about this issue too, in the context of games. We may want > to turn profiling only for certain frames (essentially, this is many small > profile runs). > > However, I have not seen it demonstrated that this kind of refined data > collection will actually improve PGO results in

I have thought about this issue too, in the context of games. We may want to turn profiling only for certain frames (essentially, this is many small profile runs). However, I have not seen it demonstrated that this kind of refined data collection will actually improve PGO results in practice. The evidence I do have though is that IIRC Apple have found that almost all of the benefits of PGO for