Can you share your project, even just with Apple at https://bugreport.apple.com? If not, can you share a built IPA for your app?

Suspicion: Xcode 10.3 is somehow adding a lot more Runtime Search Paths, or this app has so many dynamic libraries that adding one more Runtime Search Path (/usr/lib/swift) caused…well, that seems unrealistic.

Most of the time within dyld is spent on realpath, as noted by Werner on the forums; most of the time within that is spent on getattrlist.

Comment by Artem Loenko (JIRA)

It seems that we have the same issue in Badoo. And, yeah, we have a lot of dynamic libraries. I will try to gather the data for our applications today and attach it to the ticket.

Comment by Werner Altewischer (JIRA)

I created an associated bug at bugreport.apple.com: https://bugreport.apple.com/web/?problemID=51154245

I uploaded the two IPAs used for testing there: one compiled with Swift 5.0 and one compiled with Swift 4.2.1.

Thanks!

Comment by Artem Loenko (JIRA)

Sorry for the delay, took some time to investigate the problem.
It seems that we have a different issue. In our case, the regression during the startup caused not by Swift Toolchain but by the recent iOS releases.

We tested the same code-base with Swift 4.2.1/5.0.1 and on iOS 12.1.4/12.3.1. You can check the results on the screenshot below:

The strangest thing is that the regression is not "visible" when you ask dyld to print statistics during the launch. But it is visible with dtrace.

Right now, we have the following conclusions:

• the regression is related to dyld behaviour that probably was changed with iOS 12.2 release (ABI or shared Swift standard libraries perhaps?);

• the main degradations in the performance are within ImageLoader::recursiveBindWithAccounting and ImageLoader::recursiveInitialization;

• the issue is not related directly to Swift Toolchain ❓.

So, I created a radar (51257011) for Apple Xcode/build system team.
Let me know if you need more information or have questions.

P.S. the main reason is the same as in the initial description but it is not reproducible on iOS < 12.2 for us:

• dyld behaviour has changed between iOS 12.1.4 and iOS 12.3 (12.2?)

  • From Xcode 10.2 Release Notes: Swift libraries are now found in the dyld cache when the main project isn’t written in Swift. (48385698);

• the main differences are within ImageLoader::recursiveBindWithAccounting call when dyld calls ImageLoaderMegaDylib::findImageIndex:

  • on iOS < 12.3 the next call is ImageLoaderMegaDylib::hasDylib which tries to passthrough the tree with ImageLoader::trieWalk and it looks like a cheap operation;

  • on iOS >= 12.3 the next call is ImageLoaderMachO::getRPaths which tries to call realpath$DARWIN_EXTSN and realpath is reading attributes with getattrlist function;

• the second regression is related to ImageLoaderMegaDylib::findExportedSymbolAddress:

  • on iOS < 12.3 it calls ImageLoaderMachOCompressed::findShallowExportedSymbol;

  • on iOS >= 12.3 it calls ImageLoaderMegaDylib::findImageIndex which calls ImageLoaderMachO::getRPaths as in the first scenario;

• it looks like the getattrlist is very expensive because CPU usage on these calls is around 100% and IO is affected as well.

Comment by Artem Loenko (JIRA)

wernera77 (JIRA User), hi. Do you have any news about the issue? We found the main reason (in the comments above) but it seems that it is impossible to solve it on our side. So, we are trying to switch to static linking to reduce the regression.