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

Reply via email to