2c: one run would be enough for parity with the current state of the art. Something more complicated will probably bring marginal benefits

But which benchmark?

I was thinking something along the lines of for each run, assigning a symbol a fractional rank in (0,1), averaging the ranks for each symbol, and then after aggregating sort by those ranks, breaking any (unlikely) ties arbitrarily. WDYT?

We chatted with mattcary@ offline, realized that:
1. library prefetcher seems to be enabled on all cold starts, even on Go
2. sorting symbols that start executing after library prefetch kicks in would probably not reduce random IO
3. profiling the start with about:blank (with general loading benchmarks) should probably be good enough for startup perf because library prefetching has been started at this point
4. choosing one of the runs is probably as good as aggregating over multiple runs (otherwise our per-thread sorting would probably have showed some benefits, but it did not)

Chatted with Benoit, he agrees. 

To confirm:

We will start the launch candidate with the current, unordered-within-phase orderfile. Only if performance worsens will we revist this decision. 

Keeping this bug open as P3.

Covered as part of clustering work, see  crbug.com/894827