Re: [swift-dev] -whole-module-optimization with -Onone
I've also come up with a small repro case that shows the duplicated bridging header work: https://bugs.swift.org/browse/SR-3338. Thanks! Ben On Fri, Dec 2, 2016 at 3:28 PM, Ben Asher <benashe...@gmail.com> wrote: > Filed the issues I ran into with repro cases here: > > https://bugs.swift.org/browse/SR-3319 > https://bugs.swift.org/browse/SR-3321 > > SR-3321 covers the SIL verification failure. The assertion failure was in > the same file as the one that repro'd the SIL verification failure, but I'm > not seeing it anymore. If/when SR-3321 gets fixed, I'll follow up again and > see if it shows up. > > Thanks! > > Ben > > On Thu, Dec 1, 2016 at 7:10 PM, Ben Asher <benashe...@gmail.com> wrote: > >> Sure thing! I’ll see if I can put small reproducers together tomorrow. >> >> Ben >> >> On Thu, Dec 1, 2016 at 7:08 PM, Mark Lacey <mark_la...@apple.com> wrote: >> >>> >>> On Dec 1, 2016, at 5:48 PM, Ben Asher via swift-dev <swift-dev@swift.org> >>> wrote: >>> >>> The build failed compiling 3 files in our project. Our app is crashing >>> that snapshot; here is some output from the failures: >>> >>> >>> It would be awesome if you could come up with small reproducers for >>> these and open bugs for them. Alternately, opening a radar with the full >>> project attached will give us an opportunity to get these fixed ASAP! >>> >>> Mark >>> >>> >>> - Assertion failed: (newType == type || (isa(newType) && >>> cast(newType)->getNumElements() == 1 && >>> cast(newType).getElementType(0) == type)), function >>> rewriteType, file /Users/buildn >>> ode/jenkins/workspace/oss-swift-package-osx/swift/lib/SILGen/RValue.h, >>> line 207. >>> >>> - SIL verification failed: method's Self parameter should be constrained >>> by protocol: selfRequirement.getKind() == RequirementKind::Conformance && >>> selfRequirement.getFirstType()->isEqual(selfGenericParam) && selfR >>> equirement.getSecondType()->getAs() ->getDecl() == >>> protocol >>> >>> We're not getting all the way to linking, but compiling everything for >>> that snapshot took ~11min45s. Based on that, it appears that about a minute >>> is saved with the new fixes since the Swift 3.0 that shipped with Xcode 8.1 >>> (App Store). >>> >>> With Xcode 8.2 Beta 2, the app builds fine, and it takes about 12m15s. >>> If Xcode 8.2 Beta 2 also has those fixes that we expect to speed up the >>> build, the extra time here (compared to the snapshot) could be explained by >>> linking, signing, and a few other custom builds scripts that run after >>> compiling. >>> >>> Thanks everyone for your help! >>> >>> Ben >>> >>> >>> On Thu, Dec 1, 2016 at 4:16 PM, Ben Asher <benashe...@gmail.com> wrote: >>> >>>> 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 *)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&g
Re: [swift-dev] -whole-module-optimization with -Onone
Filed the issues I ran into with repro cases here: https://bugs.swift.org/browse/SR-3319 https://bugs.swift.org/browse/SR-3321 SR-3321 covers the SIL verification failure. The assertion failure was in the same file as the one that repro'd the SIL verification failure, but I'm not seeing it anymore. If/when SR-3321 gets fixed, I'll follow up again and see if it shows up. Thanks! Ben On Thu, Dec 1, 2016 at 7:10 PM, Ben Asher <benashe...@gmail.com> wrote: > Sure thing! I’ll see if I can put small reproducers together tomorrow. > > Ben > > On Thu, Dec 1, 2016 at 7:08 PM, Mark Lacey <mark_la...@apple.com> wrote: > >> >> On Dec 1, 2016, at 5:48 PM, Ben Asher via swift-dev <swift-dev@swift.org> >> wrote: >> >> The build failed compiling 3 files in our project. Our app is crashing >> that snapshot; here is some output from the failures: >> >> >> It would be awesome if you could come up with small reproducers for these >> and open bugs for them. Alternately, opening a radar with the full project >> attached will give us an opportunity to get these fixed ASAP! >> >> Mark >> >> >> - Assertion failed: (newType == type || (isa(newType) && >> cast(newType)->getNumElements() == 1 && >> cast(newType).getElementType(0) == type)), function >> rewriteType, file /Users/buildn >> ode/jenkins/workspace/oss-swift-package-osx/swift/lib/SILGen/RValue.h, >> line 207. >> >> - SIL verification failed: method's Self parameter should be constrained >> by protocol: selfRequirement.getKind() == RequirementKind::Conformance && >> selfRequirement.getFirstType()->isEqual(selfGenericParam) && selfR >> equirement.getSecondType()->getAs() ->getDecl() == protocol >> >> We're not getting all the way to linking, but compiling everything for >> that snapshot took ~11min45s. Based on that, it appears that about a minute >> is saved with the new fixes since the Swift 3.0 that shipped with Xcode 8.1 >> (App Store). >> >> With Xcode 8.2 Beta 2, the app builds fine, and it takes about 12m15s. If >> Xcode 8.2 Beta 2 also has those fixes that we expect to speed up the build, >> the extra time here (compared to the snapshot) could be explained by >> linking, signing, and a few other custom builds scripts that run after >> compiling. >> >> Thanks everyone for your help! >> >> Ben >> >> >> On Thu, Dec 1, 2016 at 4:16 PM, Ben Asher <benashe...@gmail.com> wrote: >> >>> 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 *)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 >>>>
Re: [swift-dev] -whole-module-optimization with -Onone
Sure thing! I’ll see if I can put small reproducers together tomorrow. Ben On Thu, Dec 1, 2016 at 7:08 PM, Mark Lacey <mark_la...@apple.com> wrote: > > On Dec 1, 2016, at 5:48 PM, Ben Asher via swift-dev <swift-dev@swift.org> > wrote: > > The build failed compiling 3 files in our project. Our app is crashing > that snapshot; here is some output from the failures: > > > It would be awesome if you could come up with small reproducers for these > and open bugs for them. Alternately, opening a radar with the full project > attached will give us an opportunity to get these fixed ASAP! > > Mark > > > - Assertion failed: (newType == type || (isa(newType) && > cast(newType)->getNumElements() == 1 && > cast(newType).getElementType(0) == type)), function > rewriteType, file /Users/buildn > ode/jenkins/workspace/oss-swift-package-osx/swift/lib/SILGen/RValue.h, > line 207. > > - SIL verification failed: method's Self parameter should be constrained > by protocol: selfRequirement.getKind() == RequirementKind::Conformance && > selfRequirement.getFirstType()->isEqual(selfGenericParam) && selfR > equirement.getSecondType()->getAs() ->getDecl() == protocol > > We're not getting all the way to linking, but compiling everything for > that snapshot took ~11min45s. Based on that, it appears that about a minute > is saved with the new fixes since the Swift 3.0 that shipped with Xcode 8.1 > (App Store). > > With Xcode 8.2 Beta 2, the app builds fine, and it takes about 12m15s. If > Xcode 8.2 Beta 2 also has those fixes that we expect to speed up the build, > the extra time here (compared to the snapshot) could be explained by > linking, signing, and a few other custom builds scripts that run after > compiling. > > Thanks everyone for your help! > > Ben > > > On Thu, Dec 1, 2016 at 4:16 PM, Ben Asher <benashe...@gmail.com> wrote: > >> 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 *)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 >>>>> >>>>>
Re: [swift-dev] -whole-module-optimization with -Onone
The build failed compiling 3 files in our project. Our app is crashing that snapshot; here is some output from the failures: - Assertion failed: (newType == type || (isa(newType) && cast(newType)->getNumElements() == 1 && cast(newType).getElementType(0) == type)), function rewriteType, file /Users/buildn ode/jenkins/workspace/oss-swift-package-osx/swift/lib/SILGen/RValue.h, line 207. - SIL verification failed: method's Self parameter should be constrained by protocol: selfRequirement.getKind() == RequirementKind::Conformance && selfRequirement.getFirstType()->isEqual(selfGenericParam) && selfR equirement.getSecondType()->getAs() ->getDecl() == protocol We're not getting all the way to linking, but compiling everything for that snapshot took ~11min45s. Based on that, it appears that about a minute is saved with the new fixes since the Swift 3.0 that shipped with Xcode 8.1 (App Store). With Xcode 8.2 Beta 2, the app builds fine, and it takes about 12m15s. If Xcode 8.2 Beta 2 also has those fixes that we expect to speed up the build, the extra time here (compared to the snapshot) could be explained by linking, signing, and a few other custom builds scripts that run after compiling. Thanks everyone for your help! Ben On Thu, Dec 1, 2016 at 4:16 PM, Ben Asher <benashe...@gmail.com> wrote: > 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 *)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-
Re: [swift-dev] -whole-module-optimization with -Onone
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 ___ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
Re: [swift-dev] -whole-module-optimization with -Onone
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. 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> wrote: > >> 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
Re: [swift-dev] Compilation performance
This is awesome. Thanks Graydon!! Ben On Wed, Nov 2, 2016 at 6:43 PM, Graydon Hoare via swift-dev < swift-dev@swift.org> wrote: > Hi, > > I've been working a bit on testing infrastructure for systematically > improving swiftc compilation performance. Attached is a document > summarizing both the machinery I put together, and an example (small) bug > recently fixed, as a case study showing how to use it. > > I'd like to encourage folks interested in swiftc compile times to take a > read through; especially if you happen to have an existing bug, or pattern > of bad performance you're seeing (or even have a hunch about), I'd be > interested to know if a scaling test can capture it. I'll be working > through some compilation performance bugs using this framework for the next > while, so if anyone would like to collaborate on investigating something, > let me know and I'd be happy to help. > > Thanks, > > -Graydon > > > ___ > swift-dev mailing list > swift-dev@swift.org > https://lists.swift.org/mailman/listinfo/swift-dev > > -- -Ben ___ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
Re: [swift-dev] Reporting/Debugging Slow Swift Compile Time
;>>>
>>>> 1. Take a look at the output of -debug-time-function-bodies to see if
>>>> the same function is getting type checked multiple times, and determine
>>>> what the cumulative time for those functions is.
>>>>
>>>> For example below is the output I see for a simple test case. Note that
>>>> the getter/setter that are generated from a property on line 2 of two.swift
>>>> are type checked twice. Although in this case we type check the individual
>>>> functions very quickly, if you have enough of this kind of redundant type
>>>> checking happening, it can add up. This *particular* case is a known bug
>>>> that we hope to address - the synthesized getters/setters for properties
>>>> are type checked in each file they are referenced in.
>>>>
>>>> There may be other cases like this that we’re not already aware of, so
>>>> it’s always good to open a bug if you find something like this.
>>>>
>>>> swiftc -c main.swift two.swift -module-name test -Xfrontend
>>>> -debug-time-function-bodies
>>>> 0.2ms main.swift:2:7 get {}
>>>> 0.2ms main.swift:2:7 set {}
>>>> 0.0ms main.swift:1:7 @objc deinit
>>>> 0.3ms main.swift:1:13 override init()
>>>> 0.2ms two.swift:2:14 get {}
>>>> 0.2ms two.swift:2:14 set {}
>>>> 0.2ms two.swift:2:14 get {}
>>>> 0.2ms two.swift:2:14 set {}
>>>> 0.0ms two.swift:1:14 @objc deinit
>>>> 0.0ms two.swift:1:14 init()
>>>>
>>>> 2. Add a timer for expression type checking and see if that helps
>>>> narrow down whether there is time being spent type checking expressions
>>>> that isn’t accounted for in -debug-time-function-bodies. There are a few
>>>> places that might make sense for this, but I suspect
>>>> ConstraintSystem::solve()
>>>> might be the best. This is ultimately called from a variety of places, and
>>>> would provide the most insight into where time is being spent in the
>>>> expression type checking. It’s possible something higher up the stack, like
>>>> TypeChecker::solveForExpression or TypeChecker::typeCheckExpression()
>>>> might make more sense as well. You can model this on how
>>>> -debug-time-function-bodies is currently implemented, e.g. look
>>>> at swift::performTypeChecking for some help on getting started. I’ll
>>>> probably try to add this timer myself in the next few weeks if you don’t
>>>> manage to beat me to it.
>>>>
>>>> Mark
>>>>
>>>>
>>>> I don't mind building from Swift master, using someone's preferred
>>>> profiling tools, etc. I'm not really sure where to start.
>>>>
>>>> Ben
>>>>
>>>> On Wed, Oct 5, 2016 at 1:05 PM, Ben Asher <benashe...@gmail.com> wrote:
>>>>
>>>>> Apologies for not starting off with system info: macOS Sierra
>>>>> (10.12.0), Xcode 8.0 (from the App Store).
>>>>>
>>>>> I'll try with Xcode 8.1 beta this afternoon and report back. Ill also
>>>>> open a ticket for improving -debug-time-function-bodies if I can confirm
>>>>> anything.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Ben
>>>>>
>>>>> On Wed, Oct 5, 2016 at 1:00 PM, Mark Lacey <mark.la...@apple.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> On Oct 4, 2016, at 2:38 PM, Ben Asher via swift-dev <
>>>>>> swift-dev@swift.org> wrote:
>>>>>>
>>>>>> Hello! I work with a large project (~900 .swift files and more .m
>>>>>> files). We have a nightly job that compiles the app and calls out
>>>>>> function
>>>>>> bodies (using -debug-time-function-bodies) that are slower than
>>>>>> 100ms to compile. Since upgrading to Swift 3, the number of trouble
>>>>>> function bodies has one from > 150 to < 20, so we're really happy about
>>>>>> that! The only issue though is that build time overall increased by ~1
>>>>>> min
>>>>>> (amount of time to build all targets before automatically merging to
>>>>>> master
>>>>>> in our integration build).
>>>>>>
>>>>>>
>>>>>> Is this using a particular release of Xcode (8.0 or an 8.1 beta?), or
>&g
Re: [swift-dev] Reporting/Debugging Slow Swift Compile Time
-c main.swift two.swift -module-name test -Xfrontend
>>> -debug-time-function-bodies
>>> 0.2ms main.swift:2:7 get {}
>>> 0.2ms main.swift:2:7 set {}
>>> 0.0ms main.swift:1:7 @objc deinit
>>> 0.3ms main.swift:1:13 override init()
>>> 0.2ms two.swift:2:14 get {}
>>> 0.2ms two.swift:2:14 set {}
>>> 0.2ms two.swift:2:14 get {}
>>> 0.2ms two.swift:2:14 set {}
>>> 0.0ms two.swift:1:14 @objc deinit
>>> 0.0ms two.swift:1:14 init()
>>>
>>> 2. Add a timer for expression type checking and see if that helps narrow
>>> down whether there is time being spent type checking expressions that isn’t
>>> accounted for in -debug-time-function-bodies. There are a few places that
>>> might make sense for this, but I suspect ConstraintSystem::solve()
>>> might be the best. This is ultimately called from a variety of places, and
>>> would provide the most insight into where time is being spent in the
>>> expression type checking. It’s possible something higher up the stack, like
>>> TypeChecker::solveForExpression or TypeChecker::typeCheckExpression()
>>> might make more sense as well. You can model this on how
>>> -debug-time-function-bodies is currently implemented, e.g. look
>>> at swift::performTypeChecking for some help on getting started. I’ll
>>> probably try to add this timer myself in the next few weeks if you don’t
>>> manage to beat me to it.
>>>
>>> Mark
>>>
>>>
>>> I don't mind building from Swift master, using someone's preferred
>>> profiling tools, etc. I'm not really sure where to start.
>>>
>>> Ben
>>>
>>> On Wed, Oct 5, 2016 at 1:05 PM, Ben Asher <benashe...@gmail.com> wrote:
>>>
>>>> Apologies for not starting off with system info: macOS Sierra
>>>> (10.12.0), Xcode 8.0 (from the App Store).
>>>>
>>>> I'll try with Xcode 8.1 beta this afternoon and report back. Ill also
>>>> open a ticket for improving -debug-time-function-bodies if I can confirm
>>>> anything.
>>>>
>>>> Thanks!
>>>>
>>>> Ben
>>>>
>>>> On Wed, Oct 5, 2016 at 1:00 PM, Mark Lacey <mark.la...@apple.com>
>>>> wrote:
>>>>
>>>>>
>>>>> On Oct 4, 2016, at 2:38 PM, Ben Asher via swift-dev <
>>>>> swift-dev@swift.org> wrote:
>>>>>
>>>>> Hello! I work with a large project (~900 .swift files and more .m
>>>>> files). We have a nightly job that compiles the app and calls out function
>>>>> bodies (using -debug-time-function-bodies) that are slower than 100ms
>>>>> to compile. Since upgrading to Swift 3, the number of trouble function
>>>>> bodies has one from > 150 to < 20, so we're really happy about that! The
>>>>> only issue though is that build time overall increased by ~1 min (amount
>>>>> of
>>>>> time to build all targets before automatically merging to master in our
>>>>> integration build).
>>>>>
>>>>>
>>>>> Is this using a particular release of Xcode (8.0 or an 8.1 beta?), or
>>>>> with one of the toolchain builds from swift.org?
>>>>>
>>>>> Xcode 8.1 beta 2 includes some type checker performance improvements
>>>>> which might have an impact here.
>>>>>
>>>>>
>>>>> To dig into this further, we've started a new nightly job that builds
>>>>> the app using the -debug-time-compilation flag, and using that we've found
>>>>> that some files take as long as 2-3 seconds to compile. But, there's no
>>>>> targeted output to help us get this down via the
>>>>> -debug-time-function-bodies flag (i.e. no function bodies that we can
>>>>> refactor to get compile times much faster).
>>>>>
>>>>>
>>>>> One thing to look out for here is that I believe there are some cases
>>>>> where -debug-time-function-bodies isn’t reporting type checking time. From
>>>>> my (potentially faulty) recollection, things like let bindings with
>>>>> literals or closures on the right hand side do not show up in the
>>>>> -debug-time-function-bodies output, and depending on the specifics of the
>>>>> expression these can sometimes take a long time to type check. When these
>>>>> appear within the body of another type declaration they can end up getting
>>>>> type checked multiple times during a full project build, and that time can
>>>>> add up.
>>>>>
>>>>> I don’t believe there is a bug open for improving
>>>>> -debug-time-function-bodies to help diagnose this, but opening a bug would
>>>>> be appreciated if you can confirm that this is the case, and of course
>>>>> patches to fix it are definitely welcome as well.
>>>>>
>>>>> Mark
>>>>>
>>>>> We can see that most of the time is spent in "Type checking / Semantic
>>>>> analysis" for these problem files, but we don't currently have any way of
>>>>> knowing what that means. It feels like we've exhausted the available
>>>>> options at this point (unless there are other flags I'm missing) in terms
>>>>> of existing actionable debugging/profiling/reporting, so now our question
>>>>> is this: what kind of reports would Swift maintainers be interested in
>>>>> seeing in terms of output from profiling tools, etc. to help
>>>>> debug/diagnose
>>>>> these slow compile issues? We're willing to devote time to tooling to help
>>>>> generate such reports and file bugs.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Ben
>>>>> ___
>>>>> swift-dev mailing list
>>>>> swift-dev@swift.org
>>>>> https://lists.swift.org/mailman/listinfo/swift-dev
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> -Ben
>>>>
>>>
>>>
>>>
>>> --
>>> -Ben
>>>
>>>
>>>
>>
>>
>> --
>> -Ben
>>
>
>
>
> --
> -Ben
>
>
>
--
-Ben
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
Re: [swift-dev] Reporting/Debugging Slow Swift Compile Time
om Swift master, using someone's preferred >> profiling tools, etc. I'm not really sure where to start. >> >> Ben >> >> On Wed, Oct 5, 2016 at 1:05 PM, Ben Asher <benashe...@gmail.com> wrote: >> >>> Apologies for not starting off with system info: macOS Sierra (10.12.0), >>> Xcode 8.0 (from the App Store). >>> >>> I'll try with Xcode 8.1 beta this afternoon and report back. Ill also >>> open a ticket for improving -debug-time-function-bodies if I can confirm >>> anything. >>> >>> Thanks! >>> >>> Ben >>> >>> On Wed, Oct 5, 2016 at 1:00 PM, Mark Lacey <mark.la...@apple.com> wrote: >>> >>>> >>>> On Oct 4, 2016, at 2:38 PM, Ben Asher via swift-dev < >>>> swift-dev@swift.org> wrote: >>>> >>>> Hello! I work with a large project (~900 .swift files and more .m >>>> files). We have a nightly job that compiles the app and calls out function >>>> bodies (using -debug-time-function-bodies) that are slower than 100ms >>>> to compile. Since upgrading to Swift 3, the number of trouble function >>>> bodies has one from > 150 to < 20, so we're really happy about that! The >>>> only issue though is that build time overall increased by ~1 min (amount of >>>> time to build all targets before automatically merging to master in our >>>> integration build). >>>> >>>> >>>> Is this using a particular release of Xcode (8.0 or an 8.1 beta?), or >>>> with one of the toolchain builds from swift.org? >>>> >>>> Xcode 8.1 beta 2 includes some type checker performance improvements >>>> which might have an impact here. >>>> >>>> >>>> To dig into this further, we've started a new nightly job that builds >>>> the app using the -debug-time-compilation flag, and using that we've found >>>> that some files take as long as 2-3 seconds to compile. But, there's no >>>> targeted output to help us get this down via the >>>> -debug-time-function-bodies flag (i.e. no function bodies that we can >>>> refactor to get compile times much faster). >>>> >>>> >>>> One thing to look out for here is that I believe there are some cases >>>> where -debug-time-function-bodies isn’t reporting type checking time. From >>>> my (potentially faulty) recollection, things like let bindings with >>>> literals or closures on the right hand side do not show up in the >>>> -debug-time-function-bodies output, and depending on the specifics of the >>>> expression these can sometimes take a long time to type check. When these >>>> appear within the body of another type declaration they can end up getting >>>> type checked multiple times during a full project build, and that time can >>>> add up. >>>> >>>> I don’t believe there is a bug open for improving >>>> -debug-time-function-bodies to help diagnose this, but opening a bug would >>>> be appreciated if you can confirm that this is the case, and of course >>>> patches to fix it are definitely welcome as well. >>>> >>>> Mark >>>> >>>> We can see that most of the time is spent in "Type checking / Semantic >>>> analysis" for these problem files, but we don't currently have any way of >>>> knowing what that means. It feels like we've exhausted the available >>>> options at this point (unless there are other flags I'm missing) in terms >>>> of existing actionable debugging/profiling/reporting, so now our question >>>> is this: what kind of reports would Swift maintainers be interested in >>>> seeing in terms of output from profiling tools, etc. to help debug/diagnose >>>> these slow compile issues? We're willing to devote time to tooling to help >>>> generate such reports and file bugs. >>>> >>>> Thanks! >>>> >>>> Ben >>>> ___ >>>> swift-dev mailing list >>>> swift-dev@swift.org >>>> https://lists.swift.org/mailman/listinfo/swift-dev >>>> >>>> >>>> >>> >>> >>> -- >>> -Ben >>> >> >> >> >> -- >> -Ben >> >> >> > > > -- > -Ben > -- -Ben ___ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
Re: [swift-dev] Reporting/Debugging Slow Swift Compile Time
I just tried with both Xcode 8.1 beta 2 and Xcode 8.0, and 8.1b2 seems maybe 15s faster (to build our main huge target): 7m28s compared to 7m43s. It's some improvement, but I'm not exactly sure what kind of improvement was expected. Is there any profiling/tracing you all would recommend to help find problem areas? I don't mind building from Swift master, using someone's preferred profiling tools, etc. I'm not really sure where to start. Ben On Wed, Oct 5, 2016 at 1:05 PM, Ben Asher <benashe...@gmail.com> wrote: > Apologies for not starting off with system info: macOS Sierra (10.12.0), > Xcode 8.0 (from the App Store). > > I'll try with Xcode 8.1 beta this afternoon and report back. Ill also open > a ticket for improving -debug-time-function-bodies if I can confirm > anything. > > Thanks! > > Ben > > On Wed, Oct 5, 2016 at 1:00 PM, Mark Lacey <mark.la...@apple.com> wrote: > >> >> On Oct 4, 2016, at 2:38 PM, Ben Asher via swift-dev <swift-dev@swift.org> >> wrote: >> >> Hello! I work with a large project (~900 .swift files and more .m files). >> We have a nightly job that compiles the app and calls out function bodies >> (using -debug-time-function-bodies) that are slower than 100ms to >> compile. Since upgrading to Swift 3, the number of trouble function bodies >> has one from > 150 to < 20, so we're really happy about that! The only >> issue though is that build time overall increased by ~1 min (amount of time >> to build all targets before automatically merging to master in our >> integration build). >> >> >> Is this using a particular release of Xcode (8.0 or an 8.1 beta?), or >> with one of the toolchain builds from swift.org? >> >> Xcode 8.1 beta 2 includes some type checker performance improvements >> which might have an impact here. >> >> >> To dig into this further, we've started a new nightly job that builds the >> app using the -debug-time-compilation flag, and using that we've found that >> some files take as long as 2-3 seconds to compile. But, there's no targeted >> output to help us get this down via the -debug-time-function-bodies flag >> (i.e. no function bodies that we can refactor to get compile times much >> faster). >> >> >> One thing to look out for here is that I believe there are some cases >> where -debug-time-function-bodies isn’t reporting type checking time. From >> my (potentially faulty) recollection, things like let bindings with >> literals or closures on the right hand side do not show up in the >> -debug-time-function-bodies output, and depending on the specifics of the >> expression these can sometimes take a long time to type check. When these >> appear within the body of another type declaration they can end up getting >> type checked multiple times during a full project build, and that time can >> add up. >> >> I don’t believe there is a bug open for improving >> -debug-time-function-bodies to help diagnose this, but opening a bug would >> be appreciated if you can confirm that this is the case, and of course >> patches to fix it are definitely welcome as well. >> >> Mark >> >> We can see that most of the time is spent in "Type checking / Semantic >> analysis" for these problem files, but we don't currently have any way of >> knowing what that means. It feels like we've exhausted the available >> options at this point (unless there are other flags I'm missing) in terms >> of existing actionable debugging/profiling/reporting, so now our question >> is this: what kind of reports would Swift maintainers be interested in >> seeing in terms of output from profiling tools, etc. to help debug/diagnose >> these slow compile issues? We're willing to devote time to tooling to help >> generate such reports and file bugs. >> >> 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
Re: [swift-dev] Reporting/Debugging Slow Swift Compile Time
I didn't know about that warning, so thanks for sharing that! Having this enabled will help somewhat, at least in terms of keeping specific slow-to-compile functions out of our master branch. That said, I understand Jordan's response (in SR-2741) of being "leery of 'productizing'" these flags. Developing with Swift shouldn't involve fighting the compiler to get the best compile time, so making this more than a debug flag does seem odd/worrisome. I'm more interested in the best way to get a feedback loop to understand what the known issues are and see them addressed. This has already worked well with fixes for big slowdown issues like SR-1277 and this well known patch: https://github.com/apple/swift/commit/2cdd7d64e1e2add7bcfd5452d36e7f5fc6c86a03 . On Wed, Oct 5, 2016 at 11:47 AM, Brian Gesiak <modoca...@gmail.com> wrote: > Hi Ben, > > I'd really like to see improvements here as well. I don't know what > reports would be useful to the Swift team, but allow me to point out > https://github.com/apple/swift/commit/18c75928639acf0ccf0e1fb6729eea > 75bc09cbd5, which adds a -warn-long-function-bodies option that you may > be able to use. > > However, as stated in the commit message I linked to above, both > -debug-time-function-bodies and -warn-long-function-bodies are frontend > options. They are not officially supported, and may be removed at any time > without warning. > > Personally, I think the Swift compiler should provide users with more > information about compilation times. In https://bugs.swift.org/ > browse/SR-2741, Brian Michel (cc'ed) describes a feature he'd like to > see: structured output from the Swift compiler driver, as an official, > supported option. Your team's use case sounds very similar to his, so I'd > encourage you to chime in on that issue with your thoughts. > > - Brian Gesiak > > > On Tue, Oct 4, 2016 at 5:38 PM, Ben Asher via swift-dev < > swift-dev@swift.org> wrote: > >> Hello! I work with a large project (~900 .swift files and more .m files). >> We have a nightly job that compiles the app and calls out function bodies >> (using -debug-time-function-bodies) that are slower than 100ms to >> compile. Since upgrading to Swift 3, the number of trouble function bodies >> has one from > 150 to < 20, so we're really happy about that! The only >> issue though is that build time overall increased by ~1 min (amount of time >> to build all targets before automatically merging to master in our >> integration build). >> >> To dig into this further, we've started a new nightly job that builds the >> app using the -debug-time-compilation flag, and using that we've found that >> some files take as long as 2-3 seconds to compile. But, there's no targeted >> output to help us get this down via the -debug-time-function-bodies flag >> (i.e. no function bodies that we can refactor to get compile times much >> faster). We can see that most of the time is spent in "Type checking / >> Semantic analysis" for these problem files, but we don't currently have any >> way of knowing what that means. It feels like we've exhausted the available >> options at this point (unless there are other flags I'm missing) in terms >> of existing actionable debugging/profiling/reporting, so now our question >> is this: what kind of reports would Swift maintainers be interested in >> seeing in terms of output from profiling tools, etc. to help debug/diagnose >> these slow compile issues? We're willing to devote time to tooling to help >> generate such reports and file bugs. >> >> Thanks! >> >> Ben >> >> ___ >> swift-dev mailing list >> swift-dev@swift.org >> https://lists.swift.org/mailman/listinfo/swift-dev >> >> > -- -Ben ___ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
[swift-dev] Reporting/Debugging Slow Swift Compile Time
Hello! I work with a large project (~900 .swift files and more .m files). We have a nightly job that compiles the app and calls out function bodies (using -debug-time-function-bodies) that are slower than 100ms to compile. Since upgrading to Swift 3, the number of trouble function bodies has one from > 150 to < 20, so we're really happy about that! The only issue though is that build time overall increased by ~1 min (amount of time to build all targets before automatically merging to master in our integration build). To dig into this further, we've started a new nightly job that builds the app using the -debug-time-compilation flag, and using that we've found that some files take as long as 2-3 seconds to compile. But, there's no targeted output to help us get this down via the -debug-time-function-bodies flag (i.e. no function bodies that we can refactor to get compile times much faster). We can see that most of the time is spent in "Type checking / Semantic analysis" for these problem files, but we don't currently have any way of knowing what that means. It feels like we've exhausted the available options at this point (unless there are other flags I'm missing) in terms of existing actionable debugging/profiling/reporting, so now our question is this: what kind of reports would Swift maintainers be interested in seeing in terms of output from profiling tools, etc. to help debug/diagnose these slow compile issues? We're willing to devote time to tooling to help generate such reports and file bugs. Thanks! Ben ___ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
