I'm trying out DEVELOPMENT-SNAPSHOT-2016-11-29-a now. It's still going, so I don't have any time results yet. But, I did notice something new (or maybe existed before but didn't have this warning to expose it). For every Swift file that's compiled (only using -Onone here), it outputs the same 2 warnings (easy to fix, but not related to any of this) from the same method in the same Obj-C header referring to the arguments and the return types in that method:
- "array parameter is missing a nullability type specifier (_Nonnull, _Nullable, or _Null_unspecified)" - "inferring '_Nonnull' for pointer type within array is deprecated" Here's an example of what this method looks like: + (NSSet<SomeObject *> *)setWithSELs:(SEL[])sels count:(NSUInteger)count; Could this point to more duplicated work? Ben On Thu, Dec 1, 2016 at 2:50 PM, Ben Asher <benashe...@gmail.com> wrote: > Sure! Thanks for reminding me. I'll follow up on that, test, and get back > to you. > > Ben > > On Thu, Dec 1, 2016 at 2:48 PM, Mark Lacey <mark_la...@apple.com> wrote: > >> >> On Dec 1, 2016, at 3:13 PM, Ben Asher via swift-dev <swift-dev@swift.org> >> wrote: >> >> Just running a quick trial before and after I made this change in our >> project, we were previously seeing builds of our main target that took just >> under 13min. With this hack, a clean debug build takes about 4.5min. >> >> >> You may find that recent snapshot builds from swift.org help with your >> build times even without enabling -Owholemodule. The redundant type >> checking of synthesized accessors which we talked about a month or two >> should now be fixed on master, and it would be great to verify that’s the >> case with your code and to get an idea of how much it improves your build >> times. >> >> Mark >> >> >> Ben >> >> On Thu, Dec 1, 2016 at 1:33 PM, Ben Asher <benashe...@gmail.com> wrote: >> >>> Okay I think that worked! And just to clarify, you meant set >>> SWIFT_OPTIMIZATION_LEVEL = -Owholemodule and OTHER_SWIFT_FLAGS = -Onone ? >>> >>> I'll file a radar this afternoon with some details and DM you the number. >>> >>> Thanks again! >>> >>> Ben >>> >>> On Thu, Dec 1, 2016 at 1:10 PM, Jordan Rose <jordan_r...@apple.com> w >>> rote: >>> >>>> Xcode needs to know that you're building in WMO mode, so rather than >>>> putting -whole-module-optimization in your "Other Swift Flags", put -Onone >>>> there. It's an ugly hack but it should work in the near term. >>>> >>>> We do want to work to make this drastic speed difference go away, so if >>>> you're able we (at Apple) would love to have a source drop of your Swift 3 >>>> project, for additional data on where the problems are. Mind filing a >>>> Radar? >>>> >>>> Best, >>>> Jordan >>>> >>>> >>>> > On Dec 1, 2016, at 11:51, Ben Asher via swift-dev < >>>> swift-dev@swift.org> wrote: >>>> > >>>> > Hello! Someone recently tipped me off to using >>>> -whole-module-optimization flag with -Onone for use during debug builds to >>>> speed up compile times. In our project, the speedup feels quite dramatic, >>>> but when it gets to the linking step (after compiling both Swift and Obj-C >>>> in the project) it fails because ld can't find the individual object files >>>> that normally get emitted during the debug-type build presumably because >>>> -whole-module-optimization only emits one (and this isn't a normal >>>> "-Owholemodule"-type build which works fine). >>>> > >>>> > I can't seem to reproduce this outside of Xcode, but I was curious if >>>> anyone has tried this and knows of a workaround to get >>>> -whole-module-optimization to work with -Onone in Xcode? >>>> > >>>> > I'm currently using Xcode 8.1 (App Store build) and Swift 3 on macOS >>>> Sierra. >>>> > >>>> > Thanks! >>>> > >>>> > Ben >>>> > _______________________________________________ >>>> > swift-dev mailing list >>>> > swift-dev@swift.org >>>> > https://lists.swift.org/mailman/listinfo/swift-dev >>>> >>>> >>> >>> >>> -- >>> Ben >>> >> >> >> >> -- >> Ben >> _______________________________________________ >> swift-dev mailing list >> swift-dev@swift.org >> https://lists.swift.org/mailman/listinfo/swift-dev >> >> >> > > > -- > Ben > -- Ben
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev