-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[Foundation] Reorder _DataStorage to save 14 bytes of overhead #14989
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
Conversation
@swift-ci please test |
Build failed |
@swift-ci please clean test |
Build failed |
@swift-ci please test Linux |
Build failed |
The failure listed has nothing to do with Data itself from what I can tell. |
I hit it too. @aciidb0mb3r, know what's up with llbuild? |
Dunno, this seems new. /cc @ddunbar |
We've been messing with the driver, so it could be our side too. Weird that it's not hitting the regular builders, though. |
I did change llbuild to build in release mode, maybe that is somehow related. |
@Aciid maybe related to change to build in release mode? Should we revert? |
Ah, yes, that would do it. You turned on -O and -wmo but didn't pass -num-threads, so it assumed you wanted a single object file in the current directory instead of respecting the output file map. And I believe we can't warn about this because Xcode always provides the same output file map for both WMO and non-WMO builds. |
Reproduces locally if I try to build bindings. Reverting.. |
Raised this to disable release mode when building bindings swiftlang/swift-llbuild#233 |
Thanks for the help hunting down this failure. @swift-ci please smoke test |
@swift-ci please smoke test macOS |
@shahmishal do you know what is going on here? it does not seem to be responding to me. this has been outstanding for a long while and id like to eventually get this landed. |
It smoke tested successfully. It's the full test that hasn't updated (and won't), but that's not strictly blocking you from merging. |
Superseded by #28327 |
The backing storage for Data (_DataStorage) previously would require an allocation size of 72 bytes for the overs, however re-ordering the members to a more compact layout can easily yield considerably less. We can shave off 14 bytes and hit a mark of 58 bytes per storage for the ivars; which can easily fit into a smaller bucket size (not accounting for the class information).
This resolves the following issues:
rdar://problem/38150740