firebase-ios-sdk: Extremely slow compile time of Objective-C files and dependencies
[REQUIRED] Step 1: Describe your environment
- Xcode version: 14.0 Beta 1
- Firebase SDK version: 9.1.0
- Installation method:
Swift Package Manager - Firebase Component: Promises - dependency, Crashlytics
- Target platform(s):
iOS
[REQUIRED] Step 2: Describe the problem
When building the app in new Xcode 14.0 Beta 1 - new Build Timeline is available to show you the build and compile times. Firebase and mainly it’s dependencies we didn’t choose to use are the biggest slowdown of our compile times. (see an attachment)
It would be nice to either:
- Improve compile time of the dependency
- Try to find a way how to release the framework without these dependencies
Build environment: MacBook Pro M1 Max, 32GB, Xcode 14.0 Beta 1, iOS 16 beta 1 simulator of iPhone 13 Pro
Steps to reproduce:
Include Crashlytics + Analytics + Messaging in your project via SPM and run Build (Compile) with new Xcode - then check the Build Timeline.
Additional notes
I did open an issue in the dependency itself (promises), but wanted to cross-link it here for shared knowledge - but it’s also Crashlytics problem.
I do think this is related to the new and still better Swift-optimized compiler and build system, but maybe it’s the right time to migrate relevant Objective-C code to Swift too?
Let me know if I can be helpful here somehow. Thanks for looking into this!
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 5
- Comments: 17 (8 by maintainers)
I compiled the entire project (performance traces are generated per-file). The package manager should not affect the compile times, but I can try again with SPM if you’d like.
@dingtianran The same happens on Intel macs as well, not just Apple Silicons.
Sure thing, thanks again for the report! We’re excited to see how we can improve our build times.
That’s really long time. 😄 I’ll keep an eye on this and the files that take longer than expected. Thanks for digging into this, every build time improvement is huge improvement for everyone!
Okay I ran it locally and saw really strange results. My hunch: some of these long times include waiting time until the next file can build. Example:
dummy.mtook 439 seconds to build… which is an empty file. I’ll try to dig into the WWDC sessions to see if this is explained further, or maybe it’s time to file some Feedback.My build:
Thanks the for the report! We’re keen to dig into this more - one strange thing in particular is
GULNSData+zlib.mseemingly taking 13+ seconds when it’s less than 200 lines of code: https://github.com/google/GoogleUtilities/blob/main/GoogleUtilities/NSData%2Bzlib/GULNSData%2Bzlib.mHunch: maybe it has to do with the ObjC categories, as FBLPromises also is longer than expected.