Re: [swift-users] Improving compilation times?

[piotr gorzelany via swift-users]

Jon,

I enabled this setting in a Swift 3.1 project in Xcode 8.3 and incremental
builds work as usual. The project does not recompile when making small
changes. But I did notice a great decrease in build time for my project.

Maybe the recompiles only happen on big changes? Because when I change one
or two files it seems that there is only incremental compilation.

wt., 28 mar 2017 o 20:58 użytkownik Jon Shier  napisał:

> That setting breaks incremental compilation, so you're getting clean build
> speed at the expense of incremental builds.
>
>
>
> Jon
>
> On Mar 28, 2017, at 7:35 AM, Bartłomiej Nowak via swift-users <
> swift-users@swift.org> wrote:
>
> I’ve had the same issue and adding a user-defined setting 
> `SWIFT_WHOLE_MODULE_OPTIMIZATION
> = YES` seemed to fix this. Down from 12 minutes to 2.5 after clean -> build.
>
> The question is why do we have to set such flags in Xcode ourselves, when
> it most probably should be the default setting?
>
>
> Wiadomość napisana przez Mark Lacey via swift-users 
> w dniu 23.03.2017, o godz. 18:06:
>
>
> On Mar 23, 2017, at 10:02 AM, piotr gorzelany 
> wrote:
>
> I tried using it with the latest Xcode release (version 8.2).
>
>
> That was released prior to the addition of the new option. Recent snapshot
> builds from https://swift.org/download/#snapshots as well as the more
> recent Xcode 8.3 betas have it.
>
> Mark
>
> W dniu czw., 23.03.2017 o 17:57 Mark Lacey 
> napisał(a):
>
> On Mar 23, 2017, at 1:58 AM, piotr gorzelany 
> wrote:
>
> Hi Mark,
>
> Thanks for the answer, its great to know that somebody is working on it!
>
> I tried to add the -Xfrontend -debug-time-expression-type-checking in
> Xcode in the Other Swift Flags section but that gives me an error when
> compiling
>
> :0: error: unknown argument:
> '-debug-time-expression-type-checking'
>
> Should I rather compile it on the command line using this option?
>
>
> I added this to the compiler within the last couple months so you need to
> be using a recent build in order to use this command-line option. Where did
> the compiler that you tried it with come from?
>
> Mark
>
>
> Regards,
> Piotr
>
> czw., 23 mar 2017 o 08:54 użytkownik Mark Lacey via swift-users <
> swift-users@swift.org> napisał:
>
>
> > On Mar 23, 2017, at 12:32 AM, Rien via swift-users <
> swift-users@swift.org> wrote:
> >
> >
> >> On 23 Mar 2017, at 08:27, David Hart  wrote:
> >>
> >> Yes, it's best to avoid concatenating strings with +. Not only for
> performance reasons, but it's also less readable than string interpolation:
> >>
> >> str += "No: \(count), HostIp: \(clientIp ?? "?") at port: \(service ??
> "?")\n”
> >
> > Concatenation may cause the increase, but this solved it too:
> >
> >let (clientIpOrNil, serviceOrNil) =
> sockaddrDescription(info.pointee.ai_addr)
> >let clientIp = clientIpOrNil ?? "?"
> >let service = serviceOrNil ?? "?"
> >str += "No: \(count), HostIp: " + clientIp + " at port: " +
> service + "\n”
>
> To make a long story short, expressions combining the results of
> nil-coalescing with other operators tend to be very slow to type check at
> the moment. I’m working on fixing this (really the more general issue as it
> is not specific to ?? but I’ve seen several bug reports that involve that
> operator).
>
> I added another command-line option to help track issues like this down
> (at the expression level, rather than function level):
>   -Xfrontend -debug-time-expression-type-checking
>
> If you use that you’ll see a line for every expression that is
> type-checked, with source location information, and the time to type check
> the expression. In some cases we may not have valid source information (I
> believe this generally happens for things the compiler synthesizes rather
> than user code), and you’ll see ‘’ rather than the
> file/line/column info.
>
> Mark
>
>
> >
> > Regards,
> > Rien.
> >
> >
> >>
> >> On 23 Mar 2017, at 08:11, Rien via swift-users 
> wrote:
> >>
> >>> Thanks for that link, used it to track down the worst compile time
> offender:
> >>>
> >>> This piece of code:
> >>>
> >>> public func logAddrInfoIPAddresses(_ infoPtr:
> UnsafeMutablePointer) -> String {
> >>>
> >>>   let addrInfoNil: UnsafeMutablePointer? = nil
> >>>   var count: Int = 0
> >>>   var info: UnsafeMutablePointer = infoPtr
> >>>   var str: String = ""
> >>>
> >>>   while info != addrInfoNil {
> >>>
> >>>   let (clientIp, service) =
> sockaddrDescription(info.pointee.ai_addr)
> >>>   str += "No: \(count), HostIp: " + (clientIp ?? "?") + " at port:
> " + (service ?? "?") + "\n"
> >>>   count += 1
> >>>   info = info.pointee.ai_next
> >>>   }
> >>>   return str
> >>> }
> >>>
> >>> Took 38 seconds to compile.
> >>>
> >>> Removing the “str” assignment:
> >>>
> >>> public func logAddrInfoIPAddresses(_ infoPtr:
> 

Re: [swift-users] Improving compilation times?

[Jon Shier via swift-users]

That setting breaks incremental compilation, so you're getting clean build 
speed at the expense of incremental builds. 



Jon

> On Mar 28, 2017, at 7:35 AM, Bartłomiej Nowak via swift-users 
>  wrote:
> 
> I’ve had the same issue and adding a user-defined setting 
> `SWIFT_WHOLE_MODULE_OPTIMIZATION = YES` seemed to fix this. Down from 12 
> minutes to 2.5 after clean -> build.
> 
> The question is why do we have to set such flags in Xcode ourselves, when it 
> most probably should be the default setting?
> 
> 
>>> Wiadomość napisana przez Mark Lacey via swift-users  
>>> w dniu 23.03.2017, o godz. 18:06:
>>> 
>>> 
>>> On Mar 23, 2017, at 10:02 AM, piotr gorzelany  
>>> wrote:
>>> 
>>> I tried using it with the latest Xcode release (version 8.2).
>> 
>> That was released prior to the addition of the new option. Recent snapshot 
>> builds from https://swift.org/download/#snapshots as well as the more recent 
>> Xcode 8.3 betas have it.
>> 
>> Mark
>> 
>>> W dniu czw., 23.03.2017 o 17:57 Mark Lacey  
>>> napisał(a):
> On Mar 23, 2017, at 1:58 AM, piotr gorzelany  
> wrote:
> 
> Hi Mark,
> 
> Thanks for the answer, its great to know that somebody is working on it!
> 
> I tried to add the -Xfrontend -debug-time-expression-type-checking in 
> Xcode in the Other Swift Flags section but that gives me an error when 
> compiling 
> 
> :0: error: unknown argument: 
> '-debug-time-expression-type-checking'
> 
> Should I rather compile it on the command line using this option?
 
 I added this to the compiler within the last couple months so you need to 
 be using a recent build in order to use this command-line option. Where 
 did the compiler that you tried it with come from?
 
 Mark
 
> 
> Regards,
> Piotr
> 
> czw., 23 mar 2017 o 08:54 użytkownik Mark Lacey via swift-users 
>  napisał:
> 
> > On Mar 23, 2017, at 12:32 AM, Rien via swift-users 
> >  wrote:
> >
> >
> >> On 23 Mar 2017, at 08:27, David Hart  wrote:
> >>
> >> Yes, it's best to avoid concatenating strings with +. Not only for 
> >> performance reasons, but it's also less readable than string 
> >> interpolation:
> >>
> >> str += "No: \(count), HostIp: \(clientIp ?? "?") at port: \(service ?? 
> >> "?")\n”
> >
> > Concatenation may cause the increase, but this solved it too:
> >
> >let (clientIpOrNil, serviceOrNil) = 
> > sockaddrDescription(info.pointee.ai_addr)
> >let clientIp = clientIpOrNil ?? "?"
> >let service = serviceOrNil ?? "?"
> >str += "No: \(count), HostIp: " + clientIp + " at port: " + 
> > service + "\n”
> 
> To make a long story short, expressions combining the results of 
> nil-coalescing with other operators tend to be very slow to type check at 
> the moment. I’m working on fixing this (really the more general issue as 
> it is not specific to ?? but I’ve seen several bug reports that involve 
> that operator).
> 
> I added another command-line option to help track issues like this down 
> (at the expression level, rather than function level):
>   -Xfrontend -debug-time-expression-type-checking
> 
> If you use that you’ll see a line for every expression that is 
> type-checked, with source location information, and the time to type 
> check the expression. In some cases we may not have valid source 
> information (I believe this generally happens for things the compiler 
> synthesizes rather than user code), and you’ll see ‘’ rather 
> than the file/line/column info.
> 
> Mark
> 
> 
> >
> > Regards,
> > Rien.
> >
> >
> >>
> >> On 23 Mar 2017, at 08:11, Rien via swift-users  
> >> wrote:
> >>
> >>> Thanks for that link, used it to track down the worst compile time 
> >>> offender:
> >>>
> >>> This piece of code:
> >>>
> >>> public func logAddrInfoIPAddresses(_ infoPtr: 
> >>> UnsafeMutablePointer) -> String {
> >>>
> >>>   let addrInfoNil: UnsafeMutablePointer? = nil
> >>>   var count: Int = 0
> >>>   var info: UnsafeMutablePointer = infoPtr
> >>>   var str: String = ""
> >>>
> >>>   while info != addrInfoNil {
> >>>
> >>>   let (clientIp, service) = 
> >>> sockaddrDescription(info.pointee.ai_addr)
> >>>   str += "No: \(count), HostIp: " + (clientIp ?? "?") + " at 
> >>> port: " + (service ?? "?") + "\n"
> >>>   count += 1
> >>>   info = info.pointee.ai_next
> >>>   }
> >>>   return str
> >>> }
> >>>
> >>> Took 38 seconds to compile.
> >>>
> >>> Removing 

Re: [swift-users] Improving compilation times?

[Bartłomiej Nowak via swift-users]

I’ve had the same issue and adding a user-defined setting 
`SWIFT_WHOLE_MODULE_OPTIMIZATION = YES` seemed to fix this. Down from 12 
minutes to 2.5 after clean -> build.

The question is why do we have to set such flags in Xcode ourselves, when it 
most probably should be the default setting?


> Wiadomość napisana przez Mark Lacey via swift-users  w 
> dniu 23.03.2017, o godz. 18:06:
> 
> 
>> On Mar 23, 2017, at 10:02 AM, piotr gorzelany > > wrote:
>> 
>> I tried using it with the latest Xcode release (version 8.2).
> 
> That was released prior to the addition of the new option. Recent snapshot 
> builds from https://swift.org/download/#snapshots 
>  as well as the more recent Xcode 8.3 
> betas have it.
> 
> Mark
> 
>> W dniu czw., 23.03.2017 o 17:57 Mark Lacey > > napisał(a):
>>> On Mar 23, 2017, at 1:58 AM, piotr gorzelany >> > wrote:
>>> 
>>> Hi Mark,
>>> 
>>> Thanks for the answer, its great to know that somebody is working on it!
>>> 
>>> I tried to add the -Xfrontend -debug-time-expression-type-checking in Xcode 
>>> in the Other Swift Flags section but that gives me an error when compiling 
>>> 
>>> :0: error: unknown argument: '-debug-time-expression-type-checking'
>>> 
>>> Should I rather compile it on the command line using this option?
>> 
>> I added this to the compiler within the last couple months so you need to be 
>> using a recent build in order to use this command-line option. Where did the 
>> compiler that you tried it with come from?
>> 
>> Mark
>> 
>>> 
>>> Regards,
>>> Piotr
>>> 
>>> czw., 23 mar 2017 o 08:54 użytkownik Mark Lacey via swift-users 
>>> > napisał:
>>> 
>>> > On Mar 23, 2017, at 12:32 AM, Rien via swift-users >> > > wrote:
>>> >
>>> >
>>> >> On 23 Mar 2017, at 08:27, David Hart >> >> > wrote:
>>> >>
>>> >> Yes, it's best to avoid concatenating strings with +. Not only for 
>>> >> performance reasons, but it's also less readable than string 
>>> >> interpolation:
>>> >>
>>> >> str += "No: \(count), HostIp: \(clientIp ?? "?") at port: \(service ?? 
>>> >> "?")\n”
>>> >
>>> > Concatenation may cause the increase, but this solved it too:
>>> >
>>> >let (clientIpOrNil, serviceOrNil) = 
>>> > sockaddrDescription(info.pointee.ai_addr)
>>> >let clientIp = clientIpOrNil ?? "?"
>>> >let service = serviceOrNil ?? "?"
>>> >str += "No: \(count), HostIp: " + clientIp + " at port: " + 
>>> > service + "\n”
>>> 
>>> To make a long story short, expressions combining the results of 
>>> nil-coalescing with other operators tend to be very slow to type check at 
>>> the moment. I’m working on fixing this (really the more general issue as it 
>>> is not specific to ?? but I’ve seen several bug reports that involve that 
>>> operator).
>>> 
>>> I added another command-line option to help track issues like this down (at 
>>> the expression level, rather than function level):
>>>   -Xfrontend -debug-time-expression-type-checking
>>> 
>>> If you use that you’ll see a line for every expression that is 
>>> type-checked, with source location information, and the time to type check 
>>> the expression. In some cases we may not have valid source information (I 
>>> believe this generally happens for things the compiler synthesizes rather 
>>> than user code), and you’ll see ‘’ rather than the 
>>> file/line/column info.
>>> 
>>> Mark
>>> 
>>> 
>>> >
>>> > Regards,
>>> > Rien.
>>> >
>>> >
>>> >>
>>> >> On 23 Mar 2017, at 08:11, Rien via swift-users >> >> > wrote:
>>> >>
>>> >>> Thanks for that link, used it to track down the worst compile time 
>>> >>> offender:
>>> >>>
>>> >>> This piece of code:
>>> >>>
>>> >>> public func logAddrInfoIPAddresses(_ infoPtr: 
>>> >>> UnsafeMutablePointer) -> String {
>>> >>>
>>> >>>   let addrInfoNil: UnsafeMutablePointer? = nil
>>> >>>   var count: Int = 0
>>> >>>   var info: UnsafeMutablePointer = infoPtr
>>> >>>   var str: String = ""
>>> >>>
>>> >>>   while info != addrInfoNil {
>>> >>>
>>> >>>   let (clientIp, service) = 
>>> >>> sockaddrDescription(info.pointee.ai_addr)
>>> >>>   str += "No: \(count), HostIp: " + (clientIp ?? "?") + " at port: 
>>> >>> " + (service ?? "?") + "\n"
>>> >>>   count += 1
>>> >>>   info = info.pointee.ai_next
>>> >>>   }
>>> >>>   return str
>>> >>> }
>>> >>>
>>> >>> Took 38 seconds to compile.
>>> >>>
>>> >>> Removing the “str” assignment:
>>> >>>
>>> >>> public func logAddrInfoIPAddresses(_ infoPtr: 
>>> >>> UnsafeMutablePointer) -> String {
>>> >>>
>>> >>>   let addrInfoNil: UnsafeMutablePointer? = nil
>>> >>>   var count: Int = 0
>>> 

Re: [swift-users] Improving compilation times?

[Mark Lacey via swift-users]

> On Mar 23, 2017, at 10:02 AM, piotr gorzelany  
> wrote:
> 
> I tried using it with the latest Xcode release (version 8.2).

That was released prior to the addition of the new option. Recent snapshot 
builds from https://swift.org/download/#snapshots 
 as well as the more recent Xcode 8.3 
betas have it.

Mark

> W dniu czw., 23.03.2017 o 17:57 Mark Lacey  > napisał(a):
>> On Mar 23, 2017, at 1:58 AM, piotr gorzelany > > wrote:
>> 
>> Hi Mark,
>> 
>> Thanks for the answer, its great to know that somebody is working on it!
>> 
>> I tried to add the -Xfrontend -debug-time-expression-type-checking in Xcode 
>> in the Other Swift Flags section but that gives me an error when compiling 
>> 
>> :0: error: unknown argument: '-debug-time-expression-type-checking'
>> 
>> Should I rather compile it on the command line using this option?
> 
> I added this to the compiler within the last couple months so you need to be 
> using a recent build in order to use this command-line option. Where did the 
> compiler that you tried it with come from?
> 
> Mark
> 
>> 
>> Regards,
>> Piotr
>> 
>> czw., 23 mar 2017 o 08:54 użytkownik Mark Lacey via swift-users 
>> > napisał:
>> 
>> > On Mar 23, 2017, at 12:32 AM, Rien via swift-users > > > wrote:
>> >
>> >
>> >> On 23 Mar 2017, at 08:27, David Hart > >> > wrote:
>> >>
>> >> Yes, it's best to avoid concatenating strings with +. Not only for 
>> >> performance reasons, but it's also less readable than string 
>> >> interpolation:
>> >>
>> >> str += "No: \(count), HostIp: \(clientIp ?? "?") at port: \(service ?? 
>> >> "?")\n”
>> >
>> > Concatenation may cause the increase, but this solved it too:
>> >
>> >let (clientIpOrNil, serviceOrNil) = 
>> > sockaddrDescription(info.pointee.ai_addr)
>> >let clientIp = clientIpOrNil ?? "?"
>> >let service = serviceOrNil ?? "?"
>> >str += "No: \(count), HostIp: " + clientIp + " at port: " + service 
>> > + "\n”
>> 
>> To make a long story short, expressions combining the results of 
>> nil-coalescing with other operators tend to be very slow to type check at 
>> the moment. I’m working on fixing this (really the more general issue as it 
>> is not specific to ?? but I’ve seen several bug reports that involve that 
>> operator).
>> 
>> I added another command-line option to help track issues like this down (at 
>> the expression level, rather than function level):
>>   -Xfrontend -debug-time-expression-type-checking
>> 
>> If you use that you’ll see a line for every expression that is type-checked, 
>> with source location information, and the time to type check the expression. 
>> In some cases we may not have valid source information (I believe this 
>> generally happens for things the compiler synthesizes rather than user 
>> code), and you’ll see ‘’ rather than the file/line/column info.
>> 
>> Mark
>> 
>> 
>> >
>> > Regards,
>> > Rien.
>> >
>> >
>> >>
>> >> On 23 Mar 2017, at 08:11, Rien via swift-users > >> > wrote:
>> >>
>> >>> Thanks for that link, used it to track down the worst compile time 
>> >>> offender:
>> >>>
>> >>> This piece of code:
>> >>>
>> >>> public func logAddrInfoIPAddresses(_ infoPtr: 
>> >>> UnsafeMutablePointer) -> String {
>> >>>
>> >>>   let addrInfoNil: UnsafeMutablePointer? = nil
>> >>>   var count: Int = 0
>> >>>   var info: UnsafeMutablePointer = infoPtr
>> >>>   var str: String = ""
>> >>>
>> >>>   while info != addrInfoNil {
>> >>>
>> >>>   let (clientIp, service) = sockaddrDescription(info.pointee.ai_addr)
>> >>>   str += "No: \(count), HostIp: " + (clientIp ?? "?") + " at port: " 
>> >>> + (service ?? "?") + "\n"
>> >>>   count += 1
>> >>>   info = info.pointee.ai_next
>> >>>   }
>> >>>   return str
>> >>> }
>> >>>
>> >>> Took 38 seconds to compile.
>> >>>
>> >>> Removing the “str” assignment:
>> >>>
>> >>> public func logAddrInfoIPAddresses(_ infoPtr: 
>> >>> UnsafeMutablePointer) -> String {
>> >>>
>> >>>   let addrInfoNil: UnsafeMutablePointer? = nil
>> >>>   var count: Int = 0
>> >>>   var info: UnsafeMutablePointer = infoPtr
>> >>>   var str: String = ""
>> >>>
>> >>>   while info != addrInfoNil {
>> >>>
>> >>>   let (clientIp, service) = sockaddrDescription(info.pointee.ai_addr)
>> >>> //str += "No: \(count), HostIp: " + (clientIp ?? "?") + " at 
>> >>> port: " + (service ?? "?") + "\n"
>> >>>   count += 1
>> >>>   info = info.pointee.ai_next
>> >>>   }
>> >>>   return str
>> >>> }
>> >>>
>> >>> Brought it down to 6.6ms
>> >>>
>> >>> Obviously I have to rewrite, but it does show how just one line of code 
>> >>> can be responsible for approx 80% 

Re: [swift-users] Improving compilation times?

[piotr gorzelany via swift-users]

I tried using it with the latest Xcode release (version 8.2).
W dniu czw., 23.03.2017 o 17:57 Mark Lacey 
napisał(a):

> On Mar 23, 2017, at 1:58 AM, piotr gorzelany 
> wrote:
>
> Hi Mark,
>
> Thanks for the answer, its great to know that somebody is working on it!
>
> I tried to add the -Xfrontend -debug-time-expression-type-checking in
> Xcode in the Other Swift Flags section but that gives me an error when
> compiling
>
> :0: error: unknown argument:
> '-debug-time-expression-type-checking'
>
> Should I rather compile it on the command line using this option?
>
>
> I added this to the compiler within the last couple months so you need to
> be using a recent build in order to use this command-line option. Where did
> the compiler that you tried it with come from?
>
> Mark
>
>
> Regards,
> Piotr
>
> czw., 23 mar 2017 o 08:54 użytkownik Mark Lacey via swift-users <
> swift-users@swift.org> napisał:
>
>
> > On Mar 23, 2017, at 12:32 AM, Rien via swift-users <
> swift-users@swift.org> wrote:
> >
> >
> >> On 23 Mar 2017, at 08:27, David Hart  wrote:
> >>
> >> Yes, it's best to avoid concatenating strings with +. Not only for
> performance reasons, but it's also less readable than string interpolation:
> >>
> >> str += "No: \(count), HostIp: \(clientIp ?? "?") at port: \(service ??
> "?")\n”
> >
> > Concatenation may cause the increase, but this solved it too:
> >
> >let (clientIpOrNil, serviceOrNil) =
> sockaddrDescription(info.pointee.ai_addr)
> >let clientIp = clientIpOrNil ?? "?"
> >let service = serviceOrNil ?? "?"
> >str += "No: \(count), HostIp: " + clientIp + " at port: " +
> service + "\n”
>
> To make a long story short, expressions combining the results of
> nil-coalescing with other operators tend to be very slow to type check at
> the moment. I’m working on fixing this (really the more general issue as it
> is not specific to ?? but I’ve seen several bug reports that involve that
> operator).
>
> I added another command-line option to help track issues like this down
> (at the expression level, rather than function level):
>   -Xfrontend -debug-time-expression-type-checking
>
> If you use that you’ll see a line for every expression that is
> type-checked, with source location information, and the time to type check
> the expression. In some cases we may not have valid source information (I
> believe this generally happens for things the compiler synthesizes rather
> than user code), and you’ll see ‘’ rather than the
> file/line/column info.
>
> Mark
>
>
> >
> > Regards,
> > Rien.
> >
> >
> >>
> >> On 23 Mar 2017, at 08:11, Rien via swift-users 
> wrote:
> >>
> >>> Thanks for that link, used it to track down the worst compile time
> offender:
> >>>
> >>> This piece of code:
> >>>
> >>> public func logAddrInfoIPAddresses(_ infoPtr:
> UnsafeMutablePointer) -> String {
> >>>
> >>>   let addrInfoNil: UnsafeMutablePointer? = nil
> >>>   var count: Int = 0
> >>>   var info: UnsafeMutablePointer = infoPtr
> >>>   var str: String = ""
> >>>
> >>>   while info != addrInfoNil {
> >>>
> >>>   let (clientIp, service) =
> sockaddrDescription(info.pointee.ai_addr)
> >>>   str += "No: \(count), HostIp: " + (clientIp ?? "?") + " at port:
> " + (service ?? "?") + "\n"
> >>>   count += 1
> >>>   info = info.pointee.ai_next
> >>>   }
> >>>   return str
> >>> }
> >>>
> >>> Took 38 seconds to compile.
> >>>
> >>> Removing the “str” assignment:
> >>>
> >>> public func logAddrInfoIPAddresses(_ infoPtr:
> UnsafeMutablePointer) -> String {
> >>>
> >>>   let addrInfoNil: UnsafeMutablePointer? = nil
> >>>   var count: Int = 0
> >>>   var info: UnsafeMutablePointer = infoPtr
> >>>   var str: String = ""
> >>>
> >>>   while info != addrInfoNil {
> >>>
> >>>   let (clientIp, service) =
> sockaddrDescription(info.pointee.ai_addr)
> >>> //str += "No: \(count), HostIp: " + (clientIp ?? "?") + " at
> port: " + (service ?? "?") + "\n"
> >>>   count += 1
> >>>   info = info.pointee.ai_next
> >>>   }
> >>>   return str
> >>> }
> >>>
> >>> Brought it down to 6.6ms
> >>>
> >>> Obviously I have to rewrite, but it does show how just one line of
> code can be responsible for approx 80% of the compile time.
> >>>
> >>> Regards,
> >>> Rien
> >>>
> >>> Site: http://balancingrock.nl
> >>> Blog: http://swiftrien.blogspot.com
> >>> Github: http://github.com/Balancingrock
> >>> Project: http://swiftfire.nl
> >>>
> >>>
> >>>
> >>>
> >>>
>  On 22 Mar 2017, at 23:41, Greg Parker via swift-users <
> swift-users@swift.org> wrote:
> 
> >
> > On Mar 22, 2017, at 1:03 PM, piotr gorzelany via swift-users <
> swift-users@swift.org> wrote:
> >
> > Hi, I hope I reached the right mailing list to ask a question about
> tooling.
> >
> > Can somebody from the compiler or Xcode team share some tips on how
> to improve compilation times of larger Swift projects?
> >
> 

Re: [swift-users] Improving compilation times?

[Mark Lacey via swift-users]

> On Mar 23, 2017, at 1:58 AM, piotr gorzelany  
> wrote:
> 
> Hi Mark,
> 
> Thanks for the answer, its great to know that somebody is working on it!
> 
> I tried to add the -Xfrontend -debug-time-expression-type-checking in Xcode 
> in the Other Swift Flags section but that gives me an error when compiling 
> 
> :0: error: unknown argument: '-debug-time-expression-type-checking'
> 
> Should I rather compile it on the command line using this option?

I added this to the compiler within the last couple months so you need to be 
using a recent build in order to use this command-line option. Where did the 
compiler that you tried it with come from?

Mark

> 
> Regards,
> Piotr
> 
> czw., 23 mar 2017 o 08:54 użytkownik Mark Lacey via swift-users 
> > napisał:
> 
> > On Mar 23, 2017, at 12:32 AM, Rien via swift-users  > > wrote:
> >
> >
> >> On 23 Mar 2017, at 08:27, David Hart  >> > wrote:
> >>
> >> Yes, it's best to avoid concatenating strings with +. Not only for 
> >> performance reasons, but it's also less readable than string interpolation:
> >>
> >> str += "No: \(count), HostIp: \(clientIp ?? "?") at port: \(service ?? 
> >> "?")\n”
> >
> > Concatenation may cause the increase, but this solved it too:
> >
> >let (clientIpOrNil, serviceOrNil) = 
> > sockaddrDescription(info.pointee.ai_addr)
> >let clientIp = clientIpOrNil ?? "?"
> >let service = serviceOrNil ?? "?"
> >str += "No: \(count), HostIp: " + clientIp + " at port: " + service 
> > + "\n”
> 
> To make a long story short, expressions combining the results of 
> nil-coalescing with other operators tend to be very slow to type check at the 
> moment. I’m working on fixing this (really the more general issue as it is 
> not specific to ?? but I’ve seen several bug reports that involve that 
> operator).
> 
> I added another command-line option to help track issues like this down (at 
> the expression level, rather than function level):
>   -Xfrontend -debug-time-expression-type-checking
> 
> If you use that you’ll see a line for every expression that is type-checked, 
> with source location information, and the time to type check the expression. 
> In some cases we may not have valid source information (I believe this 
> generally happens for things the compiler synthesizes rather than user code), 
> and you’ll see ‘’ rather than the file/line/column info.
> 
> Mark
> 
> 
> >
> > Regards,
> > Rien.
> >
> >
> >>
> >> On 23 Mar 2017, at 08:11, Rien via swift-users  >> > wrote:
> >>
> >>> Thanks for that link, used it to track down the worst compile time 
> >>> offender:
> >>>
> >>> This piece of code:
> >>>
> >>> public func logAddrInfoIPAddresses(_ infoPtr: 
> >>> UnsafeMutablePointer) -> String {
> >>>
> >>>   let addrInfoNil: UnsafeMutablePointer? = nil
> >>>   var count: Int = 0
> >>>   var info: UnsafeMutablePointer = infoPtr
> >>>   var str: String = ""
> >>>
> >>>   while info != addrInfoNil {
> >>>
> >>>   let (clientIp, service) = sockaddrDescription(info.pointee.ai_addr)
> >>>   str += "No: \(count), HostIp: " + (clientIp ?? "?") + " at port: " 
> >>> + (service ?? "?") + "\n"
> >>>   count += 1
> >>>   info = info.pointee.ai_next
> >>>   }
> >>>   return str
> >>> }
> >>>
> >>> Took 38 seconds to compile.
> >>>
> >>> Removing the “str” assignment:
> >>>
> >>> public func logAddrInfoIPAddresses(_ infoPtr: 
> >>> UnsafeMutablePointer) -> String {
> >>>
> >>>   let addrInfoNil: UnsafeMutablePointer? = nil
> >>>   var count: Int = 0
> >>>   var info: UnsafeMutablePointer = infoPtr
> >>>   var str: String = ""
> >>>
> >>>   while info != addrInfoNil {
> >>>
> >>>   let (clientIp, service) = sockaddrDescription(info.pointee.ai_addr)
> >>> //str += "No: \(count), HostIp: " + (clientIp ?? "?") + " at 
> >>> port: " + (service ?? "?") + "\n"
> >>>   count += 1
> >>>   info = info.pointee.ai_next
> >>>   }
> >>>   return str
> >>> }
> >>>
> >>> Brought it down to 6.6ms
> >>>
> >>> Obviously I have to rewrite, but it does show how just one line of code 
> >>> can be responsible for approx 80% of the compile time.
> >>>
> >>> Regards,
> >>> Rien
> >>>
> >>> Site: http://balancingrock.nl 
> >>> Blog: http://swiftrien.blogspot.com 
> >>> Github: http://github.com/Balancingrock 
> >>> Project: http://swiftfire.nl 
> >>>
> >>>
> >>>
> >>>
> >>>
>  On 22 Mar 2017, at 23:41, Greg Parker via swift-users 
>  > wrote:
> 
> >
> > On Mar 22, 2017, at 1:03 PM, piotr gorzelany via swift-users 
> > > wrote:
> >
> > Hi, I 

Re: [swift-users] Improving compilation times?

[piotr gorzelany via swift-users]

Rien,

You can also add the flag -Xfrontend -warn-long-function-bodies=100
directly to Other Swift Flags in Xcode. Xcode will then generate warnings
for each function that compiles more than the specified amount of time
(milliseconds) you supplied in the parameter (100 in this case).

Regards,
Piotr

czw., 23 mar 2017 o 10:29 użytkownik Rien  napisał:

>
> > On 23 Mar 2017, at 10:27, Rien  wrote:
> >
> > Just tried it, did not work on the command line either, though with a
> simple message “build commands failed”
> >
> > The following command line however does work:
> >
> > xcodebuild -scheme Swiftfire clean build OTHER_SWIFT_FLAGS="-Xfrontend
> -debug-time-function-bodies" | grep .[0-9]ms | grep -v ^0.[0-9]ms | sort
> -nr > culprits.txt
> >
> > (I found that line in the link provided previously, just modified it to
> work with a workspace and with my scheme)
>
> Oeps, “without a workspace” !!!
> >
> > Regards,
> > Rien
> >
> > Site: http://balancingrock.nl
> > Blog: http://swiftrien.blogspot.com
> > Github: http://github.com/Balancingrock
> > Project: http://swiftfire.nl
> >
> >
> >
> >
> >
> >> On 23 Mar 2017, at 09:58, piotr gorzelany 
> wrote:
> >>
> >> Hi Mark,
> >>
> >> Thanks for the answer, its great to know that somebody is working on it!
> >>
> >> I tried to add the -Xfrontend -debug-time-expression-type-checking in
> Xcode in the Other Swift Flags section but that gives me an error when
> compiling
> >>
> >> :0: error: unknown argument:
> '-debug-time-expression-type-checking'
> >>
> >> Should I rather compile it on the command line using this option?
> >>
> >> Regards,
> >> Piotr
> >>
> >> czw., 23 mar 2017 o 08:54 użytkownik Mark Lacey via swift-users <
> swift-users@swift.org> napisał:
> >>
> >>> On Mar 23, 2017, at 12:32 AM, Rien via swift-users <
> swift-users@swift.org> wrote:
> >>>
> >>>
>  On 23 Mar 2017, at 08:27, David Hart  wrote:
> 
>  Yes, it's best to avoid concatenating strings with +. Not only for
> performance reasons, but it's also less readable than string interpolation:
> 
>  str += "No: \(count), HostIp: \(clientIp ?? "?") at port: \(service
> ?? "?")\n”
> >>>
> >>> Concatenation may cause the increase, but this solved it too:
> >>>
> >>>   let (clientIpOrNil, serviceOrNil) =
> sockaddrDescription(info.pointee.ai_addr)
> >>>   let clientIp = clientIpOrNil ?? "?"
> >>>   let service = serviceOrNil ?? "?"
> >>>   str += "No: \(count), HostIp: " + clientIp + " at port: " +
> service + "\n”
> >>
> >> To make a long story short, expressions combining the results of
> nil-coalescing with other operators tend to be very slow to type check at
> the moment. I’m working on fixing this (really the more general issue as it
> is not specific to ?? but I’ve seen several bug reports that involve that
> operator).
> >>
> >> I added another command-line option to help track issues like this down
> (at the expression level, rather than function level):
> >>  -Xfrontend -debug-time-expression-type-checking
> >>
> >> If you use that you’ll see a line for every expression that is
> type-checked, with source location information, and the time to type check
> the expression. In some cases we may not have valid source information (I
> believe this generally happens for things the compiler synthesizes rather
> than user code), and you’ll see ‘’ rather than the
> file/line/column info.
> >>
> >> Mark
> >>
> >>
> >>>
> >>> Regards,
> >>> Rien.
> >>>
> >>>
> 
>  On 23 Mar 2017, at 08:11, Rien via swift-users 
> wrote:
> 
> > Thanks for that link, used it to track down the worst compile time
> offender:
> >
> > This piece of code:
> >
> > public func logAddrInfoIPAddresses(_ infoPtr:
> UnsafeMutablePointer) -> String {
> >
> >  let addrInfoNil: UnsafeMutablePointer? = nil
> >  var count: Int = 0
> >  var info: UnsafeMutablePointer = infoPtr
> >  var str: String = ""
> >
> >  while info != addrInfoNil {
> >
> >  let (clientIp, service) =
> sockaddrDescription(info.pointee.ai_addr)
> >  str += "No: \(count), HostIp: " + (clientIp ?? "?") + " at
> port: " + (service ?? "?") + "\n"
> >  count += 1
> >  info = info.pointee.ai_next
> >  }
> >  return str
> > }
> >
> > Took 38 seconds to compile.
> >
> > Removing the “str” assignment:
> >
> > public func logAddrInfoIPAddresses(_ infoPtr:
> UnsafeMutablePointer) -> String {
> >
> >  let addrInfoNil: UnsafeMutablePointer? = nil
> >  var count: Int = 0
> >  var info: UnsafeMutablePointer = infoPtr
> >  var str: String = ""
> >
> >  while info != addrInfoNil {
> >
> >  let (clientIp, service) =
> sockaddrDescription(info.pointee.ai_addr)
> > //str += "No: \(count), HostIp: " + (clientIp ?? "?") + " at
> port: " + (service ?? "?") + 

Re: [swift-users] Improving compilation times?

[piotr gorzelany via swift-users]

Hi Mark,

Thanks for the answer, its great to know that somebody is working on it!

I tried to add the -Xfrontend -debug-time-expression-type-checking in Xcode
in the Other Swift Flags section but that gives me an error when compiling

:0: error: unknown argument: '-debug-time-expression-type-checking'

Should I rather compile it on the command line using this option?

Regards,
Piotr

czw., 23 mar 2017 o 08:54 użytkownik Mark Lacey via swift-users <
swift-users@swift.org> napisał:

>
> > On Mar 23, 2017, at 12:32 AM, Rien via swift-users <
> swift-users@swift.org> wrote:
> >
> >
> >> On 23 Mar 2017, at 08:27, David Hart  wrote:
> >>
> >> Yes, it's best to avoid concatenating strings with +. Not only for
> performance reasons, but it's also less readable than string interpolation:
> >>
> >> str += "No: \(count), HostIp: \(clientIp ?? "?") at port: \(service ??
> "?")\n”
> >
> > Concatenation may cause the increase, but this solved it too:
> >
> >let (clientIpOrNil, serviceOrNil) =
> sockaddrDescription(info.pointee.ai_addr)
> >let clientIp = clientIpOrNil ?? "?"
> >let service = serviceOrNil ?? "?"
> >str += "No: \(count), HostIp: " + clientIp + " at port: " +
> service + "\n”
>
> To make a long story short, expressions combining the results of
> nil-coalescing with other operators tend to be very slow to type check at
> the moment. I’m working on fixing this (really the more general issue as it
> is not specific to ?? but I’ve seen several bug reports that involve that
> operator).
>
> I added another command-line option to help track issues like this down
> (at the expression level, rather than function level):
>   -Xfrontend -debug-time-expression-type-checking
>
> If you use that you’ll see a line for every expression that is
> type-checked, with source location information, and the time to type check
> the expression. In some cases we may not have valid source information (I
> believe this generally happens for things the compiler synthesizes rather
> than user code), and you’ll see ‘’ rather than the
> file/line/column info.
>
> Mark
>
>
> >
> > Regards,
> > Rien.
> >
> >
> >>
> >> On 23 Mar 2017, at 08:11, Rien via swift-users 
> wrote:
> >>
> >>> Thanks for that link, used it to track down the worst compile time
> offender:
> >>>
> >>> This piece of code:
> >>>
> >>> public func logAddrInfoIPAddresses(_ infoPtr:
> UnsafeMutablePointer) -> String {
> >>>
> >>>   let addrInfoNil: UnsafeMutablePointer? = nil
> >>>   var count: Int = 0
> >>>   var info: UnsafeMutablePointer = infoPtr
> >>>   var str: String = ""
> >>>
> >>>   while info != addrInfoNil {
> >>>
> >>>   let (clientIp, service) =
> sockaddrDescription(info.pointee.ai_addr)
> >>>   str += "No: \(count), HostIp: " + (clientIp ?? "?") + " at port:
> " + (service ?? "?") + "\n"
> >>>   count += 1
> >>>   info = info.pointee.ai_next
> >>>   }
> >>>   return str
> >>> }
> >>>
> >>> Took 38 seconds to compile.
> >>>
> >>> Removing the “str” assignment:
> >>>
> >>> public func logAddrInfoIPAddresses(_ infoPtr:
> UnsafeMutablePointer) -> String {
> >>>
> >>>   let addrInfoNil: UnsafeMutablePointer? = nil
> >>>   var count: Int = 0
> >>>   var info: UnsafeMutablePointer = infoPtr
> >>>   var str: String = ""
> >>>
> >>>   while info != addrInfoNil {
> >>>
> >>>   let (clientIp, service) =
> sockaddrDescription(info.pointee.ai_addr)
> >>> //str += "No: \(count), HostIp: " + (clientIp ?? "?") + " at
> port: " + (service ?? "?") + "\n"
> >>>   count += 1
> >>>   info = info.pointee.ai_next
> >>>   }
> >>>   return str
> >>> }
> >>>
> >>> Brought it down to 6.6ms
> >>>
> >>> Obviously I have to rewrite, but it does show how just one line of
> code can be responsible for approx 80% of the compile time.
> >>>
> >>> Regards,
> >>> Rien
> >>>
> >>> Site: http://balancingrock.nl
> >>> Blog: http://swiftrien.blogspot.com
> >>> Github: http://github.com/Balancingrock
> >>> Project: http://swiftfire.nl
> >>>
> >>>
> >>>
> >>>
> >>>
>  On 22 Mar 2017, at 23:41, Greg Parker via swift-users <
> swift-users@swift.org> wrote:
> 
> >
> > On Mar 22, 2017, at 1:03 PM, piotr gorzelany via swift-users <
> swift-users@swift.org> wrote:
> >
> > Hi, I hope I reached the right mailing list to ask a question about
> tooling.
> >
> > Can somebody from the compiler or Xcode team share some tips on how
> to improve compilation times of larger Swift projects?
> >
> > I am an iOS developer and the largest issue my team has with Swift
> so far is that when the project gets semi large (~30 000 lines) the
> compilation times start to be high (~10 minutes from clean). This is a
> MAJOR downside since iOS development oftentimes requires rapid changes to
> UI or logic. Every person of my team compiles a project at least 10 times a
> day to test new features or functionalities. When compilation times start
> to be higher than 10 minutes 

Re: [swift-users] Improving compilation times?

[Mark Lacey via swift-users]

> On Mar 23, 2017, at 12:32 AM, Rien via swift-users  
> wrote:
> 
> 
>> On 23 Mar 2017, at 08:27, David Hart  wrote:
>> 
>> Yes, it's best to avoid concatenating strings with +. Not only for 
>> performance reasons, but it's also less readable than string interpolation:
>> 
>> str += "No: \(count), HostIp: \(clientIp ?? "?") at port: \(service ?? 
>> "?")\n”
> 
> Concatenation may cause the increase, but this solved it too:
> 
>let (clientIpOrNil, serviceOrNil) = 
> sockaddrDescription(info.pointee.ai_addr)
>let clientIp = clientIpOrNil ?? "?"
>let service = serviceOrNil ?? "?"
>str += "No: \(count), HostIp: " + clientIp + " at port: " + service + 
> "\n”

To make a long story short, expressions combining the results of nil-coalescing 
with other operators tend to be very slow to type check at the moment. I’m 
working on fixing this (really the more general issue as it is not specific to 
?? but I’ve seen several bug reports that involve that operator).

I added another command-line option to help track issues like this down (at the 
expression level, rather than function level):
  -Xfrontend -debug-time-expression-type-checking

If you use that you’ll see a line for every expression that is type-checked, 
with source location information, and the time to type check the expression. In 
some cases we may not have valid source information (I believe this generally 
happens for things the compiler synthesizes rather than user code), and you’ll 
see ‘’ rather than the file/line/column info.

Mark


> 
> Regards,
> Rien.
> 
> 
>> 
>> On 23 Mar 2017, at 08:11, Rien via swift-users  wrote:
>> 
>>> Thanks for that link, used it to track down the worst compile time offender:
>>> 
>>> This piece of code:
>>> 
>>> public func logAddrInfoIPAddresses(_ infoPtr: 
>>> UnsafeMutablePointer) -> String {
>>> 
>>>   let addrInfoNil: UnsafeMutablePointer? = nil
>>>   var count: Int = 0
>>>   var info: UnsafeMutablePointer = infoPtr
>>>   var str: String = ""
>>> 
>>>   while info != addrInfoNil {
>>> 
>>>   let (clientIp, service) = sockaddrDescription(info.pointee.ai_addr)
>>>   str += "No: \(count), HostIp: " + (clientIp ?? "?") + " at port: " + 
>>> (service ?? "?") + "\n"
>>>   count += 1
>>>   info = info.pointee.ai_next
>>>   }
>>>   return str
>>> }
>>> 
>>> Took 38 seconds to compile.
>>> 
>>> Removing the “str” assignment:
>>> 
>>> public func logAddrInfoIPAddresses(_ infoPtr: 
>>> UnsafeMutablePointer) -> String {
>>> 
>>>   let addrInfoNil: UnsafeMutablePointer? = nil
>>>   var count: Int = 0
>>>   var info: UnsafeMutablePointer = infoPtr
>>>   var str: String = ""
>>> 
>>>   while info != addrInfoNil {
>>> 
>>>   let (clientIp, service) = sockaddrDescription(info.pointee.ai_addr)
>>> //str += "No: \(count), HostIp: " + (clientIp ?? "?") + " at port: 
>>> " + (service ?? "?") + "\n"
>>>   count += 1
>>>   info = info.pointee.ai_next
>>>   }
>>>   return str
>>> }
>>> 
>>> Brought it down to 6.6ms
>>> 
>>> Obviously I have to rewrite, but it does show how just one line of code can 
>>> be responsible for approx 80% of the compile time.
>>> 
>>> Regards,
>>> Rien
>>> 
>>> Site: http://balancingrock.nl
>>> Blog: http://swiftrien.blogspot.com
>>> Github: http://github.com/Balancingrock
>>> Project: http://swiftfire.nl
>>> 
>>> 
>>> 
>>> 
>>> 
 On 22 Mar 2017, at 23:41, Greg Parker via swift-users 
  wrote:
 
> 
> On Mar 22, 2017, at 1:03 PM, piotr gorzelany via swift-users 
>  wrote:
> 
> Hi, I hope I reached the right mailing list to ask a question about 
> tooling.
> 
> Can somebody from the compiler or Xcode team share some tips on how to 
> improve compilation times of larger Swift projects?
> 
> I am an iOS developer and the largest issue my team has with Swift so far 
> is that when the project gets semi large (~30 000 lines) the compilation 
> times start to be high (~10 minutes from clean). This is a MAJOR downside 
> since iOS development oftentimes requires rapid changes to UI or logic. 
> Every person of my team compiles a project at least 10 times a day to 
> test new features or functionalities. When compilation times start to be 
> higher than 10 minutes that gets us to ~1.5h a day of developer time 
> spend just on compiling. Not to mention the focus lost when this is 
> happening.
> 
> I know the Swift Evolution list is buzzing with new ideas and features 
> but from my experience the compilation times is a CRITICAL thing to 
> improve in the next Swift release since it cost real money to waste all 
> those developer hours. Just think of all the hours lost on compiling 
> across all Swift devs worldwide and you will get to probably dozens of 
> thousand of dev hours a day.
> 
> Is the core compiler team 

Re: [swift-users] Improving compilation times?

[Rien via swift-users]

> On 23 Mar 2017, at 08:27, David Hart  wrote:
> 
> Yes, it's best to avoid concatenating strings with +. Not only for 
> performance reasons, but it's also less readable than string interpolation:
> 
> str += "No: \(count), HostIp: \(clientIp ?? "?") at port: \(service ?? "?")\n”

Concatenation may cause the increase, but this solved it too:

let (clientIpOrNil, serviceOrNil) = 
sockaddrDescription(info.pointee.ai_addr)
let clientIp = clientIpOrNil ?? "?"
let service = serviceOrNil ?? "?"
str += "No: \(count), HostIp: " + clientIp + " at port: " + service + 
"\n”

Regards,
Rien.


> 
> On 23 Mar 2017, at 08:11, Rien via swift-users  wrote:
> 
>> Thanks for that link, used it to track down the worst compile time offender:
>> 
>> This piece of code:
>> 
>> public func logAddrInfoIPAddresses(_ infoPtr: 
>> UnsafeMutablePointer) -> String {
>> 
>>let addrInfoNil: UnsafeMutablePointer? = nil
>>var count: Int = 0
>>var info: UnsafeMutablePointer = infoPtr
>>var str: String = ""
>> 
>>while info != addrInfoNil {
>> 
>>let (clientIp, service) = sockaddrDescription(info.pointee.ai_addr)
>>str += "No: \(count), HostIp: " + (clientIp ?? "?") + " at port: " + 
>> (service ?? "?") + "\n"
>>count += 1
>>info = info.pointee.ai_next
>>}
>>return str
>> }
>> 
>> Took 38 seconds to compile.
>> 
>> Removing the “str” assignment:
>> 
>> public func logAddrInfoIPAddresses(_ infoPtr: 
>> UnsafeMutablePointer) -> String {
>> 
>>let addrInfoNil: UnsafeMutablePointer? = nil
>>var count: Int = 0
>>var info: UnsafeMutablePointer = infoPtr
>>var str: String = ""
>> 
>>while info != addrInfoNil {
>> 
>>let (clientIp, service) = sockaddrDescription(info.pointee.ai_addr)
>> //str += "No: \(count), HostIp: " + (clientIp ?? "?") + " at port: " 
>> + (service ?? "?") + "\n"
>>count += 1
>>info = info.pointee.ai_next
>>}
>>return str
>> }
>> 
>> Brought it down to 6.6ms
>> 
>> Obviously I have to rewrite, but it does show how just one line of code can 
>> be responsible for approx 80% of the compile time.
>> 
>> Regards,
>> Rien
>> 
>> Site: http://balancingrock.nl
>> Blog: http://swiftrien.blogspot.com
>> Github: http://github.com/Balancingrock
>> Project: http://swiftfire.nl
>> 
>> 
>> 
>> 
>> 
>>> On 22 Mar 2017, at 23:41, Greg Parker via swift-users 
>>>  wrote:
>>> 
 
 On Mar 22, 2017, at 1:03 PM, piotr gorzelany via swift-users 
  wrote:
 
 Hi, I hope I reached the right mailing list to ask a question about 
 tooling.
 
 Can somebody from the compiler or Xcode team share some tips on how to 
 improve compilation times of larger Swift projects?
 
 I am an iOS developer and the largest issue my team has with Swift so far 
 is that when the project gets semi large (~30 000 lines) the compilation 
 times start to be high (~10 minutes from clean). This is a MAJOR downside 
 since iOS development oftentimes requires rapid changes to UI or logic. 
 Every person of my team compiles a project at least 10 times a day to test 
 new features or functionalities. When compilation times start to be higher 
 than 10 minutes that gets us to ~1.5h a day of developer time spend just 
 on compiling. Not to mention the focus lost when this is happening.
 
 I know the Swift Evolution list is buzzing with new ideas and features but 
 from my experience the compilation times is a CRITICAL thing to improve in 
 the next Swift release since it cost real money to waste all those 
 developer hours. Just think of all the hours lost on compiling across all 
 Swift devs worldwide and you will get to probably dozens of thousand of 
 dev hours a day.
 
 Is the core compiler team going to address compilation performance in the 
 next release?
 
 Maybe there is an existing solution to long compilation times that we 
 don't know of? It would be great if anybody could share.
 I was thinking maybe of dividing the app into multiple frameworks since I 
 think frameworks are compiled only once only on change?
>>> 
>>> Build time is always a goal. Pretty much every version of Swift has had 
>>> changes intended to improve compilation time or decrease the frequency of 
>>> recompilation.
>>> 
>>> Often a large part of the build time is spent in a handful of places where 
>>> the compiler's type inference system behaves poorly. You can use the 
>>> -debug-time-function-bodies and -debug-time-expression-type-checking flags 
>>> to look for these places. You can often get huge decreases in compile time 
>>> by adding an explicit type declaration in the right place in order to 
>>> simplify the type inference engine's job.
>>> 
>>> Here's a walkthough of one such analysis:
>>> Profiling your Swift compilation 

Re: [swift-users] Improving compilation times?

[David Hart via swift-users]

Yes, it's best to avoid concatenating strings with +. Not only for performance 
reasons, but it's also less readable than string interpolation:

str += "No: \(count), HostIp: \(clientIp ?? "?") at port: \(service ?? "?")\n"

> On 23 Mar 2017, at 08:11, Rien via swift-users  wrote:
> 
> Thanks for that link, used it to track down the worst compile time offender:
> 
> This piece of code:
> 
> public func logAddrInfoIPAddresses(_ infoPtr: UnsafeMutablePointer) 
> -> String {
> 
>let addrInfoNil: UnsafeMutablePointer? = nil
>var count: Int = 0
>var info: UnsafeMutablePointer = infoPtr
>var str: String = ""
> 
>while info != addrInfoNil {
> 
>let (clientIp, service) = sockaddrDescription(info.pointee.ai_addr)
>str += "No: \(count), HostIp: " + (clientIp ?? "?") + " at port: " + 
> (service ?? "?") + "\n"
>count += 1
>info = info.pointee.ai_next
>}
>return str
> }
> 
> Took 38 seconds to compile.
> 
> Removing the “str” assignment:
> 
> public func logAddrInfoIPAddresses(_ infoPtr: UnsafeMutablePointer) 
> -> String {
> 
>let addrInfoNil: UnsafeMutablePointer? = nil
>var count: Int = 0
>var info: UnsafeMutablePointer = infoPtr
>var str: String = ""
> 
>while info != addrInfoNil {
> 
>let (clientIp, service) = sockaddrDescription(info.pointee.ai_addr)
> //str += "No: \(count), HostIp: " + (clientIp ?? "?") + " at port: " 
> + (service ?? "?") + "\n"
>count += 1
>info = info.pointee.ai_next
>}
>return str
> }
> 
> Brought it down to 6.6ms
> 
> Obviously I have to rewrite, but it does show how just one line of code can 
> be responsible for approx 80% of the compile time.
> 
> Regards,
> Rien
> 
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Balancingrock
> Project: http://swiftfire.nl
> 
> 
> 
> 
> 
>>> On 22 Mar 2017, at 23:41, Greg Parker via swift-users 
>>>  wrote:
>>> 
>>> 
>>> On Mar 22, 2017, at 1:03 PM, piotr gorzelany via swift-users 
>>>  wrote:
>>> 
>>> Hi, I hope I reached the right mailing list to ask a question about tooling.
>>> 
>>> Can somebody from the compiler or Xcode team share some tips on how to 
>>> improve compilation times of larger Swift projects?
>>> 
>>> I am an iOS developer and the largest issue my team has with Swift so far 
>>> is that when the project gets semi large (~30 000 lines) the compilation 
>>> times start to be high (~10 minutes from clean). This is a MAJOR downside 
>>> since iOS development oftentimes requires rapid changes to UI or logic. 
>>> Every person of my team compiles a project at least 10 times a day to test 
>>> new features or functionalities. When compilation times start to be higher 
>>> than 10 minutes that gets us to ~1.5h a day of developer time spend just on 
>>> compiling. Not to mention the focus lost when this is happening.
>>> 
>>> I know the Swift Evolution list is buzzing with new ideas and features but 
>>> from my experience the compilation times is a CRITICAL thing to improve in 
>>> the next Swift release since it cost real money to waste all those 
>>> developer hours. Just think of all the hours lost on compiling across all 
>>> Swift devs worldwide and you will get to probably dozens of thousand of dev 
>>> hours a day.
>>> 
>>> Is the core compiler team going to address compilation performance in the 
>>> next release?
>>> 
>>> Maybe there is an existing solution to long compilation times that we don't 
>>> know of? It would be great if anybody could share.
>>> I was thinking maybe of dividing the app into multiple frameworks since I 
>>> think frameworks are compiled only once only on change?
>> 
>> Build time is always a goal. Pretty much every version of Swift has had 
>> changes intended to improve compilation time or decrease the frequency of 
>> recompilation.
>> 
>> Often a large part of the build time is spent in a handful of places where 
>> the compiler's type inference system behaves poorly. You can use the 
>> -debug-time-function-bodies and -debug-time-expression-type-checking flags 
>> to look for these places. You can often get huge decreases in compile time 
>> by adding an explicit type declaration in the right place in order to 
>> simplify the type inference engine's job.
>> 
>> Here's a walkthough of one such analysis:
>> Profiling your Swift compilation times
>> http://irace.me/swift-profiling
>> 
>> 
>> -- 
>> Greg Parker gpar...@apple.com Runtime Wrangler
>> 
>> 
>> ___
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
___
swift-users mailing list
swift-users@swift.org

Re: [swift-users] Improving compilation times?

[Rien via swift-users]

Thanks for that link, used it to track down the worst compile time offender:

This piece of code:

public func logAddrInfoIPAddresses(_ infoPtr: UnsafeMutablePointer) 
-> String {

let addrInfoNil: UnsafeMutablePointer? = nil
var count: Int = 0
var info: UnsafeMutablePointer = infoPtr
var str: String = ""

while info != addrInfoNil {

let (clientIp, service) = sockaddrDescription(info.pointee.ai_addr)
str += "No: \(count), HostIp: " + (clientIp ?? "?") + " at port: " + 
(service ?? "?") + "\n"
count += 1
info = info.pointee.ai_next
}
return str
}

Took 38 seconds to compile.

Removing the “str” assignment:

public func logAddrInfoIPAddresses(_ infoPtr: UnsafeMutablePointer) 
-> String {

let addrInfoNil: UnsafeMutablePointer? = nil
var count: Int = 0
var info: UnsafeMutablePointer = infoPtr
var str: String = ""

while info != addrInfoNil {

let (clientIp, service) = sockaddrDescription(info.pointee.ai_addr)
//str += "No: \(count), HostIp: " + (clientIp ?? "?") + " at port: " + 
(service ?? "?") + "\n"
count += 1
info = info.pointee.ai_next
}
return str
}

Brought it down to 6.6ms

Obviously I have to rewrite, but it does show how just one line of code can be 
responsible for approx 80% of the compile time.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl





> On 22 Mar 2017, at 23:41, Greg Parker via swift-users  
> wrote:
> 
>> 
>> On Mar 22, 2017, at 1:03 PM, piotr gorzelany via swift-users 
>>  wrote:
>> 
>> Hi, I hope I reached the right mailing list to ask a question about tooling.
>> 
>> Can somebody from the compiler or Xcode team share some tips on how to 
>> improve compilation times of larger Swift projects?
>> 
>> I am an iOS developer and the largest issue my team has with Swift so far is 
>> that when the project gets semi large (~30 000 lines) the compilation times 
>> start to be high (~10 minutes from clean). This is a MAJOR downside since 
>> iOS development oftentimes requires rapid changes to UI or logic. Every 
>> person of my team compiles a project at least 10 times a day to test new 
>> features or functionalities. When compilation times start to be higher than 
>> 10 minutes that gets us to ~1.5h a day of developer time spend just on 
>> compiling. Not to mention the focus lost when this is happening.
>> 
>> I know the Swift Evolution list is buzzing with new ideas and features but 
>> from my experience the compilation times is a CRITICAL thing to improve in 
>> the next Swift release since it cost real money to waste all those developer 
>> hours. Just think of all the hours lost on compiling across all Swift devs 
>> worldwide and you will get to probably dozens of thousand of dev hours a day.
>> 
>> Is the core compiler team going to address compilation performance in the 
>> next release?
>> 
>> Maybe there is an existing solution to long compilation times that we don't 
>> know of? It would be great if anybody could share.
>> I was thinking maybe of dividing the app into multiple frameworks since I 
>> think frameworks are compiled only once only on change?
> 
> Build time is always a goal. Pretty much every version of Swift has had 
> changes intended to improve compilation time or decrease the frequency of 
> recompilation.
> 
> Often a large part of the build time is spent in a handful of places where 
> the compiler's type inference system behaves poorly. You can use the 
> -debug-time-function-bodies and -debug-time-expression-type-checking flags to 
> look for these places. You can often get huge decreases in compile time by 
> adding an explicit type declaration in the right place in order to simplify 
> the type inference engine's job.
> 
> Here's a walkthough of one such analysis:
> Profiling your Swift compilation times
> http://irace.me/swift-profiling
> 
> 
> -- 
> Greg Parker gpar...@apple.com Runtime Wrangler
> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Improving compilation times?

[Chris Anderson via swift-users]

Is this information available in Apple’s documentation? I ran the script on the 
blog post you referenced it did not work for me (put the output of the build 
into the culprits.txt file instead of the analysis itself), so I went looking 
for official Apple recommendations but could not find any.

Has there been thought or work towards (in addition to speed up Swift itself) 
getting these compilation analyses into Xcode itself? I and, I would imagine, 
many other developers, would find it incredibly useful.

Best,
Chris Anderson
christopher.ander...@gmail.com

> On Mar 22, 2017, at 6:41 PM, Greg Parker via swift-users 
>  wrote:
> 
>> 
>> On Mar 22, 2017, at 1:03 PM, piotr gorzelany via swift-users 
>> > wrote:
>> 
>> Hi, I hope I reached the right mailing list to ask a question about tooling.
>> 
>> Can somebody from the compiler or Xcode team share some tips on how to 
>> improve compilation times of larger Swift projects?
>> 
>> I am an iOS developer and the largest issue my team has with Swift so far is 
>> that when the project gets semi large (~30 000 lines) the compilation times 
>> start to be high (~10 minutes from clean). This is a MAJOR downside since 
>> iOS development oftentimes requires rapid changes to UI or logic. Every 
>> person of my team compiles a project at least 10 times a day to test new 
>> features or functionalities. When compilation times start to be higher than 
>> 10 minutes that gets us to ~1.5h a day of developer time spend just on 
>> compiling. Not to mention the focus lost when this is happening.
>> 
>> I know the Swift Evolution list is buzzing with new ideas and features but 
>> from my experience the compilation times is a CRITICAL thing to improve in 
>> the next Swift release since it cost real money to waste all those developer 
>> hours. Just think of all the hours lost on compiling across all Swift devs 
>> worldwide and you will get to probably dozens of thousand of dev hours a day.
>> 
>> Is the core compiler team going to address compilation performance in the 
>> next release?
>> 
>> Maybe there is an existing solution to long compilation times that we don't 
>> know of? It would be great if anybody could share.
>> I was thinking maybe of dividing the app into multiple frameworks since I 
>> think frameworks are compiled only once only on change?
> 
> Build time is always a goal. Pretty much every version of Swift has had 
> changes intended to improve compilation time or decrease the frequency of 
> recompilation.
> 
> Often a large part of the build time is spent in a handful of places where 
> the compiler's type inference system behaves poorly. You can use the 
> -debug-time-function-bodies and -debug-time-expression-type-checking flags to 
> look for these places. You can often get huge decreases in compile time by 
> adding an explicit type declaration in the right place in order to simplify 
> the type inference engine's job.
> 
> Here's a walkthough of one such analysis:
> Profiling your Swift compilation times
> http://irace.me/swift-profiling 
> 
> -- 
> Greg Parker gpar...@apple.com  Runtime 
> Wrangler
> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-users 
> 
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Improving compilation times?

[Greg Parker via swift-users]

> On Mar 22, 2017, at 1:03 PM, piotr gorzelany via swift-users 
>  wrote:
> 
> Hi, I hope I reached the right mailing list to ask a question about tooling.
> 
> Can somebody from the compiler or Xcode team share some tips on how to 
> improve compilation times of larger Swift projects?
> 
> I am an iOS developer and the largest issue my team has with Swift so far is 
> that when the project gets semi large (~30 000 lines) the compilation times 
> start to be high (~10 minutes from clean). This is a MAJOR downside since iOS 
> development oftentimes requires rapid changes to UI or logic. Every person of 
> my team compiles a project at least 10 times a day to test new features or 
> functionalities. When compilation times start to be higher than 10 minutes 
> that gets us to ~1.5h a day of developer time spend just on compiling. Not to 
> mention the focus lost when this is happening.
> 
> I know the Swift Evolution list is buzzing with new ideas and features but 
> from my experience the compilation times is a CRITICAL thing to improve in 
> the next Swift release since it cost real money to waste all those developer 
> hours. Just think of all the hours lost on compiling across all Swift devs 
> worldwide and you will get to probably dozens of thousand of dev hours a day.
> 
> Is the core compiler team going to address compilation performance in the 
> next release?
> 
> Maybe there is an existing solution to long compilation times that we don't 
> know of? It would be great if anybody could share.
> I was thinking maybe of dividing the app into multiple frameworks since I 
> think frameworks are compiled only once only on change?

Build time is always a goal. Pretty much every version of Swift has had changes 
intended to improve compilation time or decrease the frequency of recompilation.

Often a large part of the build time is spent in a handful of places where the 
compiler's type inference system behaves poorly. You can use the 
-debug-time-function-bodies and -debug-time-expression-type-checking flags to 
look for these places. You can often get huge decreases in compile time by 
adding an explicit type declaration in the right place in order to simplify the 
type inference engine's job.

Here's a walkthough of one such analysis:
Profiling your Swift compilation times
http://irace.me/swift-profiling


-- 
Greg Parker gpar...@apple.com  Runtime 
Wrangler


___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Improving compilation times?

[Jon Shier via swift-users]

It’s a rather severe regression from Objective-C, where equivalent 
amounts of code could be compiled in 2 - 3 minutes. I think we all understand 
why swiftc is so much slower than clang, but it’s concerning that, with all of 
the talk of new features or changes for Swift 4, there’s no comment on the 
degree of effort being put into improving build times or diagnostics. I’m 
pretty sure the answer is “ongoing” but given that performance and diagnostics 
both seemed to regress from Swift 2 - 3, some in the community are concerned 
about ongoing progress and priority. Personally, I’d much rather have better 
performance, stability, and diagnostics over enhancements to the Dictionary 
API, but that’s just personal opinion.
Does Swift, in any area, have any guiding performance, stability, or 
diagnostic principles? In the early days of WebKit, and I believe still to this 
day, they had a guiding principle of no performance regressions, even for 
increased correctness. Performance losses for correctness or new features had 
to be offset by performance gains elsewhere. AFAIK, Swift has no such official 
policy. I think the community would appreciate such a commitment. I would, at 
least.



Jon Shier


> On Mar 22, 2017, at 5:59 PM, Jan Neumüller via swift-users 
>  wrote:
> 
> I may be old - But what is abnormal at 10mins compilation time? Looks 
> perfectly fine to me - I still remember hours of compilation…
> 
> Jan
> 
>> On 22 Mar 2017, at 21:03, piotr gorzelany via swift-users 
>>  wrote:
>> 
>> Hi, I hope I reached the right mailing list to ask a question about tooling.
>> 
>> Can somebody from the compiler or Xcode team share some tips on how to 
>> improve compilation times of larger Swift projects?
>> 
>> I am an iOS developer and the largest issue my team has with Swift so far is 
>> that when the project gets semi large (~30 000 lines) the compilation times 
>> start to be high (~10 minutes from clean). This is a MAJOR downside since 
>> iOS development oftentimes requires rapid changes to UI or logic. Every 
>> person of my team compiles a project at least 10 times a day to test new 
>> features or functionalities. When compilation times start to be higher than 
>> 10 minutes that gets us to ~1.5h a day of developer time spend just on 
>> compiling. Not to mention the focus lost when this is happening.
>> 
>> I know the Swift Evolution list is buzzing with new ideas and features but 
>> from my experience the compilation times is a CRITICAL thing to improve in 
>> the next Swift release since it cost real money to waste all those developer 
>> hours. Just think of all the hours lost on compiling across all Swift devs 
>> worldwide and you will get to probably dozens of thousand of dev hours a day.
>> 
>> Is the core compiler team going to address compilation performance in the 
>> next release?
>> 
>> Maybe there is an existing solution to long compilation times that we don't 
>> know of? It would be great if anybody could share.
>> I was thinking maybe of dividing the app into multiple frameworks since I 
>> think frameworks are compiled only once only on change?
>> 
>> Regards,
>> Piotr
>> ___
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Improving compilation times?

[Jan Neumüller via swift-users]

I may be old - But what is abnormal at 10mins compilation time? Looks perfectly 
fine to me - I still remember hours of compilation…

Jan

> On 22 Mar 2017, at 21:03, piotr gorzelany via swift-users 
>  wrote:
> 
> Hi, I hope I reached the right mailing list to ask a question about tooling.
> 
> Can somebody from the compiler or Xcode team share some tips on how to 
> improve compilation times of larger Swift projects?
> 
> I am an iOS developer and the largest issue my team has with Swift so far is 
> that when the project gets semi large (~30 000 lines) the compilation times 
> start to be high (~10 minutes from clean). This is a MAJOR downside since iOS 
> development oftentimes requires rapid changes to UI or logic. Every person of 
> my team compiles a project at least 10 times a day to test new features or 
> functionalities. When compilation times start to be higher than 10 minutes 
> that gets us to ~1.5h a day of developer time spend just on compiling. Not to 
> mention the focus lost when this is happening.
> 
> I know the Swift Evolution list is buzzing with new ideas and features but 
> from my experience the compilation times is a CRITICAL thing to improve in 
> the next Swift release since it cost real money to waste all those developer 
> hours. Just think of all the hours lost on compiling across all Swift devs 
> worldwide and you will get to probably dozens of thousand of dev hours a day.
> 
> Is the core compiler team going to address compilation performance in the 
> next release?
> 
> Maybe there is an existing solution to long compilation times that we don't 
> know of? It would be great if anybody could share.
> I was thinking maybe of dividing the app into multiple frameworks since I 
> think frameworks are compiled only once only on change?
> 
> Regards,
> Piotr
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

[swift-users] Improving compilation times?

[piotr gorzelany via swift-users]

Hi, I hope I reached the right mailing list to ask a question about tooling.

Can somebody from the compiler or Xcode team share some tips on how to
improve compilation times of larger Swift projects?

I am an iOS developer and the largest issue my team has with Swift so far
is that when the project gets semi large (~30 000 lines) the compilation
times start to be high (~10 minutes from clean). This is a MAJOR downside
since iOS development oftentimes requires rapid changes to UI or logic.
Every person of my team compiles a project at least 10 times a day to test
new features or functionalities. When compilation times start to be higher
than 10 minutes that gets us to ~1.5h a day of developer time spend just on
compiling. Not to mention the focus lost when this is happening.

I know the Swift Evolution list is buzzing with new ideas and features but
from my experience the compilation times is a CRITICAL thing to improve in
the next Swift release since it cost real money to waste all those
developer hours. Just think of all the hours lost on compiling across all
Swift devs worldwide and you will get to probably dozens of thousand of dev
hours a day.

Is the core compiler team going to address compilation performance in the
next release?

Maybe there is an existing solution to long compilation times that we don't
know of? It would be great if anybody could share.
I was thinking maybe of dividing the app into multiple frameworks since I
think frameworks are compiled only once only on change?

Regards,
Piotr
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users