-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Release Tooling] Add functionality to build dynamic frameworks #12890
Conversation
I manually verified by diffing the directory structure that the refactored code paths for static xcframeworks produces unchanged artifacts. |
1h 21m 35s for the dynamic linking job. Huge speedup! |
Dynamic Firebase.zip has the same directory structure of the static Firebase.zip (which makes sense since the resources bundles are moved within the static frameworks) |
Promising results with the zip looking good and ABTesting x dynamic linking test looking good as well. Will now try to test against all QS. |
The savings are spread out among the top-level directories. I did some spot checking with comparing the executables (.a vs .dylib) using Example:
The output is pretty hard to parse, but I did look for patterns of symbols being in both outputs. Size calculated using
|
@andrewheard, can you think of anything in particular to look for? |
Unfortunately I'm not sure of anything in particular to look for in addition to what you did with |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This LGTM. Since the static builds remain the default, this gives us a chance to test out the dynamic zip locally without affecting the next release. (I'm not expecting anything wrong since the quickstarts worked.)
Sharing a script I used to measure sizes, and readings of the Firestore directory. Notice how interop/extension SDKs take up more for the dynamic case.
|
Thanks. For static to dynamic increases, grpc and FirebaseFirestoreInternal are huge. Would be interesting to break those down to the individual .o files. |
#no-changelog