search for: 16m50s

...d profile without merging: ~13m10s > b) with merging > b.1) pool size == 1: ~18m20s > b.2) pool size == 2: ~16m30s > b.3) pool size == 3: ~15m55s > b.4) pool size == 4: ~16m20s > b.5) pool size == 5: ~16m42s > c) >3000 profile file without merging (%p) : ~16m50s > > Increasing the size of merge pool increases dumping parallelism -- the > performance improves initially but when it is above 4, it starts to degrade > gradually. When the HDD IO throughput is saturated at that point and > increasing parallelism does not help any more. > > I...

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