profile gls binary with pprof to spot bottlenecks in runtime

[ozansz]

Summary

Folder indexing (tree traversal) seems to be inefficient than it should be, considering it's basically a tree traversal algorithm. Use pprof tool to find out if there are any bottlenecks in the code, by either:

1. Writing a benchmark test and running it with the -benchmem, -memprofile, and -cpuprofile options
2. Setting up a pprof server by using net/http/pprof, and calling it during runtime to capture the CPU/memory dumps

[caldrian]

I'm having the same issue.

[Flash3001]

@visuall @caldrian how can you reproduce that?

Are the dylibs inside the .app/Frameworks or in .IPA/SwiftSupport that are missing?

Are you using the Archive for Publishing or the "generate IPA" build option?

[visuall]

@Flash3001 , I am using Archive for Publishing. The dylibs are not in .app/Frameworks.

[ololomax]

Looks like Xamarin now removes Headers folder in each framework during the build process. The CheckSwiftVersionsTask does not detect a swift header and thinks the framework isn't depending on swift libraries. The workaround I came up with is to apply "true" value to the _ShouldIncludeSwiftDylibs variable inside the target and not re-apply it in Output tags. Take a look at modified file: https://gist.github.com/ololomax/1e72c65c5d69ae092c22c52aa2b45f73 (you should replace your packages/Xamarin.Swift.1.0.7/build/xamarinios/Xamarin.Swift.targets with this one).

[Flash3001]

My support for this project has been awful lately, sorry about that.

I just published @ololomax changes as 1.0.8. That means that even if you target a version of iOS that already includes the Swift runtime the files will still be included in your bundle.

I was having a hard time trying to reproduce the issue. Turns out the X-Swift.h headers are removed only on Release builds.

My goal for now was to only provide the workaround so you don't need to keep changing the Nuget download folder.

I still need to stop and think about what to do. Microsoft published a package on NuGet with the same functionality (Xamarin.iOS.SwiftRuntimeSupport) and I have yet to test it and see how it behaves alongside this one.

We may have 3 options: A) Stop this project and delegate all functions to the official Microsoft package using the Nuget dependency feature. B) Find a workaround to get the required Swift version and continue with the same functionality. C) Keep the current workaround, which will always include the Swift runtime.