[Crashlytics] Improve launch performance with high priority dispatch queue

[ghugues]

Currently when no debugger is attached and Crashlytics does its full initialization work (which can be simulated by returning false from FIRCLSProcessDebuggerAttached), it blocks the main thread, waiting for initialization work to finish on several different background threads (here).

All the work the main thread is waiting on is being done on a concurrent background queue with default priority. According to someone who knows the subject well, there is no priority inversion resolution in this case. And when an iOS app starts, it is common to have a lot of initialization work being dispatched to background threads, so Crashlytics initialization will be in competition will all that work, but also block the main thread in the mean time.

Therefore, shouldn't the dispatch queue have a higher priority ? Maybe event the highest (QOS_CLASS_USER_INTERACTIVE) ? I did some tests with an optimized build, and I saw an average 35ms with DISPATCH_QUEUE_PRIORITY_DEFAULT and 25ms with QOS_CLASS_USER_INTERACTIVE (measured between the creation of the dispatch queue and the end of dispatch_group_wait). It may not somme like much, but for an already well optimized launch sequence (with most work dispatched on background threads), 10ms is actually a good performance improvement.

Also, I tried removing all the dispatch_group_async and do everything synchronously and also saw an average time of 25ms, so all this async dispatch may not be necessary ? But there may be other reasons why this was setup like this, so it may be out of scope to change it.