Improving compilation times?

[pgorzelany (Piotr Gorzelany)]

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
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

···

from my experience the compilation times is a CRITICAL thing to improve in

[gparker42 (Greg Parker)]

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

Profiling your Swift compilation times

···

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 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?

--
Greg Parker gparker@apple.com <mailto:gparker@apple.com> Runtime Wrangler

[chrisanderson]

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.anderson@gmail.com

···

On Mar 22, 2017, at 6:41 PM, 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 <mailto: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 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
Profiling your Swift compilation times · Bryan Irace

--
Greg Parker gparker@apple.com <mailto:gparker@apple.com> Runtime Wrangler

_______________________________________________
swift-users mailing list
swift-users@swift.org <mailto:swift-users@swift.org>
https://lists.swift.org/mailman/listinfo/swift-users

[anon27714269]

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 <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 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

[Rien]

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

This piece of code:

public func logAddrInfoIPAddresses(_ infoPtr: UnsafeMutablePointer<addrinfo>) -> String {
    
    let addrInfoNil: UnsafeMutablePointer<addrinfo>? = nil
    var count: Int = 0
    var info: UnsafeMutablePointer<addrinfo> = 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<addrinfo>) -> String {
    
    let addrInfoNil: UnsafeMutablePointer<addrinfo>? = nil
    var count: Int = 0
    var info: UnsafeMutablePointer<addrinfo> = 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: Balancingrock (Rien) · GitHub
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 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
Profiling your Swift compilation times · Bryan Irace

--
Greg Parker gparker@apple.com Runtime Wrangler

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

[Jon_Shier]

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 <swift-users@swift.org> 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 <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 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

[hartbit (David Hart)]

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 <swift-users@swift.org> wrote:

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

This piece of code:

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

   let addrInfoNil: UnsafeMutablePointer<addrinfo>? = nil
   var count: Int = 0
   var info: UnsafeMutablePointer<addrinfo> = 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<addrinfo>) -> String {

   let addrInfoNil: UnsafeMutablePointer<addrinfo>? = nil
   var count: Int = 0
   var info: UnsafeMutablePointer<addrinfo> = 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: Balancingrock (Rien) · GitHub
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 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
Profiling your Swift compilation times · Bryan Irace

--
Greg Parker gparker@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

[Rien]

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:27, David Hart <david@hartbit.com> wrote:

On 23 Mar 2017, at 08:11, Rien via swift-users <swift-users@swift.org> wrote:

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

This piece of code:

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

   let addrInfoNil: UnsafeMutablePointer<addrinfo>? = nil
   var count: Int = 0
   var info: UnsafeMutablePointer<addrinfo> = 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<addrinfo>) -> String {

   let addrInfoNil: UnsafeMutablePointer<addrinfo>? = nil
   var count: Int = 0
   var info: UnsafeMutablePointer<addrinfo> = 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: Balancingrock (Rien) · GitHub
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 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
Profiling your Swift compilation times · Bryan Irace

--
Greg Parker gparker@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

[rudkx (Mark Lacey)]

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 ‘<invalid loc>’ rather than the file/line/column info.

Mark

···

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 <david@hartbit.com> wrote:

Regards,
Rien.

On 23 Mar 2017, at 08:11, Rien via swift-users <swift-users@swift.org> wrote:

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

This piece of code:

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

  let addrInfoNil: UnsafeMutablePointer<addrinfo>? = nil
  var count: Int = 0
  var info: UnsafeMutablePointer<addrinfo> = 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<addrinfo>) -> String {

  let addrInfoNil: UnsafeMutablePointer<addrinfo>? = nil
  var count: Int = 0
  var info: UnsafeMutablePointer<addrinfo> = 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: Balancingrock (Rien) · GitHub
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 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
Profiling your Swift compilation times · Bryan Irace

--
Greg Parker gparker@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
https://lists.swift.org/mailman/listinfo/swift-users

[pgorzelany (Piotr Gorzelany)]

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

<unknown>: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 <david@hartbit.com> 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 ‘<invalid loc>’ rather than the
file/line/column info.

Mark

>
> Regards,
> Rien.
>
>
>>
>> On 23 Mar 2017, at 08:11, Rien via swift-users <swift-users@swift.org> > wrote:
>>
>>> Thanks for that link, used it to track down the worst compile time
offender:
>>>
>>> This piece of code:
>>>
>>> public func logAddrInfoIPAddresses(_ infoPtr:
UnsafeMutablePointer<addrinfo>) -> String {
>>>
>>> let addrInfoNil: UnsafeMutablePointer<addrinfo>? = nil
>>> var count: Int = 0
>>> var info: UnsafeMutablePointer<addrinfo> = 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<addrinfo>) -> String {
>>>
>>> let addrInfoNil: UnsafeMutablePointer<addrinfo>? = nil
>>> var count: Int = 0
>>> var info: UnsafeMutablePointer<addrinfo> = 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: Balancingrock (Rien) · GitHub
>>> 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 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
>>>> Profiling your Swift compilation times · Bryan Irace
>>>>
>>>>
>>>> --
>>>> Greg Parker gparker@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
> https://lists.swift.org/mailman/listinfo/swift-users

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

[rudkx (Mark Lacey)]

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

<unknown>: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

···

On Mar 23, 2017, at 1:58 AM, piotr gorzelany <piotr.gorzelany@gmail.com> wrote:

Regards,
Piotr

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

> On Mar 23, 2017, at 12:32 AM, Rien via swift-users <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>
>
>> On 23 Mar 2017, at 08:27, David Hart <david@hartbit.com <mailto:david@hartbit.com>> 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 ‘<invalid loc>’ rather than the file/line/column info.

Mark

>
> Regards,
> Rien.
>
>
>>
>> On 23 Mar 2017, at 08:11, Rien via swift-users <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>>
>>> Thanks for that link, used it to track down the worst compile time offender:
>>>
>>> This piece of code:
>>>
>>> public func logAddrInfoIPAddresses(_ infoPtr: UnsafeMutablePointer<addrinfo>) -> String {
>>>
>>> let addrInfoNil: UnsafeMutablePointer<addrinfo>? = nil
>>> var count: Int = 0
>>> var info: UnsafeMutablePointer<addrinfo> = 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<addrinfo>) -> String {
>>>
>>> let addrInfoNil: UnsafeMutablePointer<addrinfo>? = nil
>>> var count: Int = 0
>>> var info: UnsafeMutablePointer<addrinfo> = 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 <http://balancingrock.nl/&gt;
>>> Blog: http://swiftrien.blogspot.com <http://swiftrien.blogspot.com/&gt;
>>> Github: Balancingrock (Rien) · GitHub
>>> Project: http://swiftfire.nl <Indobet - Tempat Daftar Login Rtp Slot Gacor Indonesia;
>>>
>>>
>>>
>>>
>>>
>>>> On 22 Mar 2017, at 23:41, Greg Parker via swift-users <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>>>>
>>>>>
>>>>> On Mar 22, 2017, at 1:03 PM, piotr gorzelany via swift-users <swift-users@swift.org <mailto: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 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
>>>> Profiling your Swift compilation times · Bryan Irace
>>>>
>>>>
>>>> --
>>>> Greg Parker gparker@apple.com <mailto:gparker@apple.com> Runtime Wrangler
>>>>
>>>>
>>>> _______________________________________________
>>>> swift-users mailing list
>>>> swift-users@swift.org <mailto:swift-users@swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-users
>>>
>>> _______________________________________________
>>> swift-users mailing list
>>> swift-users@swift.org <mailto:swift-users@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-users
>
> _______________________________________________
> swift-users mailing list
> swift-users@swift.org <mailto:swift-users@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-users

_______________________________________________
swift-users mailing list
swift-users@swift.org <mailto:swift-users@swift.org>
https://lists.swift.org/mailman/listinfo/swift-users

[Rien]

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)

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: Balancingrock (Rien) · GitHub
Project: http://swiftfire.nl

···

On 23 Mar 2017, at 09:58, piotr gorzelany <piotr.gorzelany@gmail.com> 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

<unknown>: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 <david@hartbit.com> 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 ‘<invalid loc>’ rather than the file/line/column info.

Mark

>
> Regards,
> Rien.
>
>
>>
>> On 23 Mar 2017, at 08:11, Rien via swift-users <swift-users@swift.org> wrote:
>>
>>> Thanks for that link, used it to track down the worst compile time offender:
>>>
>>> This piece of code:
>>>
>>> public func logAddrInfoIPAddresses(_ infoPtr: UnsafeMutablePointer<addrinfo>) -> String {
>>>
>>> let addrInfoNil: UnsafeMutablePointer<addrinfo>? = nil
>>> var count: Int = 0
>>> var info: UnsafeMutablePointer<addrinfo> = 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<addrinfo>) -> String {
>>>
>>> let addrInfoNil: UnsafeMutablePointer<addrinfo>? = nil
>>> var count: Int = 0
>>> var info: UnsafeMutablePointer<addrinfo> = 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: Balancingrock (Rien) · GitHub
>>> 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 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
>>>> Profiling your Swift compilation times · Bryan Irace
>>>>
>>>>
>>>> --
>>>> Greg Parker gparker@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
> https://lists.swift.org/mailman/listinfo/swift-users

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

[Rien]

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” !!!

···

On 23 Mar 2017, at 10:27, Rien <rien@balancingrock.nl> wrote:

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: Balancingrock (Rien) · GitHub
Project: http://swiftfire.nl

On 23 Mar 2017, at 09:58, piotr gorzelany <piotr.gorzelany@gmail.com> 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

<unknown>: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 <david@hartbit.com> 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 ‘<invalid loc>’ rather than the file/line/column info.

Mark

Regards,
Rien.

On 23 Mar 2017, at 08:11, Rien via swift-users <swift-users@swift.org> wrote:

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

This piece of code:

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

let addrInfoNil: UnsafeMutablePointer<addrinfo>? = nil
var count: Int = 0
var info: UnsafeMutablePointer<addrinfo> = 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<addrinfo>) -> String {

let addrInfoNil: UnsafeMutablePointer<addrinfo>? = nil
var count: Int = 0
var info: UnsafeMutablePointer<addrinfo> = 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: Balancingrock (Rien) · GitHub
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 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
Profiling your Swift compilation times · Bryan Irace

--
Greg Parker gparker@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
https://lists.swift.org/mailman/listinfo/swift-users

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

[pgorzelany (Piotr Gorzelany)]

I tried using it with the latest Xcode release (version 8.2).

···

W dniu czw., 23.03.2017 o 17:57 Mark Lacey <mark.lacey@apple.com> napisał(a):

On Mar 23, 2017, at 1:58 AM, piotr gorzelany <piotr.gorzelany@gmail.com> > 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

<unknown>: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 <david@hartbit.com> 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 ‘<invalid loc>’ rather than the
file/line/column info.

Mark

>
> Regards,
> Rien.
>
>
>>
>> On 23 Mar 2017, at 08:11, Rien via swift-users <swift-users@swift.org> > wrote:
>>
>>> Thanks for that link, used it to track down the worst compile time
offender:
>>>
>>> This piece of code:
>>>
>>> public func logAddrInfoIPAddresses(_ infoPtr:
UnsafeMutablePointer<addrinfo>) -> String {
>>>
>>> let addrInfoNil: UnsafeMutablePointer<addrinfo>? = nil
>>> var count: Int = 0
>>> var info: UnsafeMutablePointer<addrinfo> = 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<addrinfo>) -> String {
>>>
>>> let addrInfoNil: UnsafeMutablePointer<addrinfo>? = nil
>>> var count: Int = 0
>>> var info: UnsafeMutablePointer<addrinfo> = 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: Balancingrock (Rien) · GitHub
>>> 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 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
>>>> Profiling your Swift compilation times · Bryan Irace
>>>>
>>>>
>>>> --
>>>> Greg Parker gparker@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
> https://lists.swift.org/mailman/listinfo/swift-users

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

[pgorzelany (Piotr Gorzelany)]

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 <Rien@balancingrock.nl> napisał:

···

> On 23 Mar 2017, at 10:27, Rien <rien@balancingrock.nl> 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: Balancingrock (Rien) · GitHub
> Project: http://swiftfire.nl
>
>
>
>
>
>> On 23 Mar 2017, at 09:58, piotr gorzelany <piotr.gorzelany@gmail.com> > 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
>>
>> <unknown>: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 <david@hartbit.com> 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 ‘<invalid loc>’ rather than the
file/line/column info.
>>
>> Mark
>>
>>
>>>
>>> Regards,
>>> Rien.
>>>
>>>
>>>>
>>>> On 23 Mar 2017, at 08:11, Rien via swift-users <swift-users@swift.org> > wrote:
>>>>
>>>>> Thanks for that link, used it to track down the worst compile time
offender:
>>>>>
>>>>> This piece of code:
>>>>>
>>>>> public func logAddrInfoIPAddresses(_ infoPtr:
UnsafeMutablePointer<addrinfo>) -> String {
>>>>>
>>>>> let addrInfoNil: UnsafeMutablePointer<addrinfo>? = nil
>>>>> var count: Int = 0
>>>>> var info: UnsafeMutablePointer<addrinfo> = 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<addrinfo>) -> String {
>>>>>
>>>>> let addrInfoNil: UnsafeMutablePointer<addrinfo>? = nil
>>>>> var count: Int = 0
>>>>> var info: UnsafeMutablePointer<addrinfo> = 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: Balancingrock (Rien) · GitHub
>>>>> 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 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
>>>>>> Profiling your Swift compilation times · Bryan Irace
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Greg Parker gparker@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
>>> https://lists.swift.org/mailman/listinfo/swift-users
>>
>> _______________________________________________
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
>

[rudkx (Mark Lacey)]

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 Swift.org - Download Swift as well as the more recent Xcode 8.3 betas have it.

Mark

···

On Mar 23, 2017, at 10:02 AM, piotr gorzelany <piotr.gorzelany@gmail.com> wrote:

W dniu czw., 23.03.2017 o 17:57 Mark Lacey <mark.lacey@apple.com <mailto:mark.lacey@apple.com>> napisał(a):

On Mar 23, 2017, at 1:58 AM, piotr gorzelany <piotr.gorzelany@gmail.com <mailto:piotr.gorzelany@gmail.com>> 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

<unknown>: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 <mailto:swift-users@swift.org>> napisał:

> On Mar 23, 2017, at 12:32 AM, Rien via swift-users <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>
>
>> On 23 Mar 2017, at 08:27, David Hart <david@hartbit.com <mailto:david@hartbit.com>> 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 ‘<invalid loc>’ rather than the file/line/column info.

Mark

>
> Regards,
> Rien.
>
>
>>
>> On 23 Mar 2017, at 08:11, Rien via swift-users <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>>
>>> Thanks for that link, used it to track down the worst compile time offender:
>>>
>>> This piece of code:
>>>
>>> public func logAddrInfoIPAddresses(_ infoPtr: UnsafeMutablePointer<addrinfo>) -> String {
>>>
>>> let addrInfoNil: UnsafeMutablePointer<addrinfo>? = nil
>>> var count: Int = 0
>>> var info: UnsafeMutablePointer<addrinfo> = 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<addrinfo>) -> String {
>>>
>>> let addrInfoNil: UnsafeMutablePointer<addrinfo>? = nil
>>> var count: Int = 0
>>> var info: UnsafeMutablePointer<addrinfo> = 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 <http://balancingrock.nl/&gt;
>>> Blog: http://swiftrien.blogspot.com <http://swiftrien.blogspot.com/&gt;
>>> Github: Balancingrock (Rien) · GitHub
>>> Project: http://swiftfire.nl <Indobet - Tempat Daftar Login Rtp Slot Gacor Indonesia;
>>>
>>>
>>>
>>>
>>>
>>>> On 22 Mar 2017, at 23:41, Greg Parker via swift-users <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>>>>
>>>>>
>>>>> On Mar 22, 2017, at 1:03 PM, piotr gorzelany via swift-users <swift-users@swift.org <mailto: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 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
>>>> Profiling your Swift compilation times · Bryan Irace
>>>>
>>>>
>>>> --
>>>> Greg Parker gparker@apple.com <mailto:gparker@apple.com> Runtime Wrangler
>>>>
>>>>
>>>> _______________________________________________
>>>> swift-users mailing list
>>>> swift-users@swift.org <mailto:swift-users@swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-users
>>>
>>> _______________________________________________
>>> swift-users mailing list
>>> swift-users@swift.org <mailto:swift-users@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-users
>
> _______________________________________________
> swift-users mailing list
> swift-users@swift.org <mailto:swift-users@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-users

_______________________________________________
swift-users mailing list
swift-users@swift.org <mailto:swift-users@swift.org>
https://lists.swift.org/mailman/listinfo/swift-users

[Bartlomiej_Nowak (Bartłomiej Nowak)]

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 <swift-users@swift.org> w dniu 23.03.2017, o godz. 18:06:

On Mar 23, 2017, at 10:02 AM, piotr gorzelany <piotr.gorzelany@gmail.com <mailto:piotr.gorzelany@gmail.com>> 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 Swift.org - Download Swift as well as the more recent Xcode 8.3 betas have it.

Mark

W dniu czw., 23.03.2017 o 17:57 Mark Lacey <mark.lacey@apple.com <mailto:mark.lacey@apple.com>> napisał(a):

On Mar 23, 2017, at 1:58 AM, piotr gorzelany <piotr.gorzelany@gmail.com <mailto:piotr.gorzelany@gmail.com>> 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

<unknown>: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 <mailto:swift-users@swift.org>> napisał:

> On Mar 23, 2017, at 12:32 AM, Rien via swift-users <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>
>
>> On 23 Mar 2017, at 08:27, David Hart <david@hartbit.com <mailto:david@hartbit.com>> 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 ‘<invalid loc>’ rather than the file/line/column info.

Mark

>
> Regards,
> Rien.
>
>
>>
>> On 23 Mar 2017, at 08:11, Rien via swift-users <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>>
>>> Thanks for that link, used it to track down the worst compile time offender:
>>>
>>> This piece of code:
>>>
>>> public func logAddrInfoIPAddresses(_ infoPtr: UnsafeMutablePointer<addrinfo>) -> String {
>>>
>>> let addrInfoNil: UnsafeMutablePointer<addrinfo>? = nil
>>> var count: Int = 0
>>> var info: UnsafeMutablePointer<addrinfo> = 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<addrinfo>) -> String {
>>>
>>> let addrInfoNil: UnsafeMutablePointer<addrinfo>? = nil
>>> var count: Int = 0
>>> var info: UnsafeMutablePointer<addrinfo> = 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 <http://balancingrock.nl/&gt;
>>> Blog: http://swiftrien.blogspot.com <http://swiftrien.blogspot.com/&gt;
>>> Github: Balancingrock (Rien) · GitHub
>>> Project: http://swiftfire.nl <Indobet - Tempat Daftar Login Rtp Slot Gacor Indonesia;
>>>
>>>
>>>
>>>
>>>
>>>> On 22 Mar 2017, at 23:41, Greg Parker via swift-users <swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
>>>>
>>>>>
>>>>> On Mar 22, 2017, at 1:03 PM, piotr gorzelany via swift-users <swift-users@swift.org <mailto: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 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
>>>> Profiling your Swift compilation times · Bryan Irace
>>>>
>>>>
>>>> --
>>>> Greg Parker gparker@apple.com <mailto:gparker@apple.com> Runtime Wrangler
>>>>
>>>>
>>>> _______________________________________________
>>>> swift-users mailing list
>>>> swift-users@swift.org <mailto:swift-users@swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-users
>>>
>>> _______________________________________________
>>> swift-users mailing list
>>> swift-users@swift.org <mailto:swift-users@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-users
>
> _______________________________________________
> swift-users mailing list
> swift-users@swift.org <mailto:swift-users@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-users

_______________________________________________
swift-users mailing list
swift-users@swift.org <mailto: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

[Jon_Shier]

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 <swift-users@swift.org> w dniu 23.03.2017, o godz. 18:06:

On Mar 23, 2017, at 10:02 AM, piotr gorzelany <piotr.gorzelany@gmail.com> 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 Swift.org - Download Swift as well as the more recent Xcode 8.3 betas have it.

Mark

W dniu czw., 23.03.2017 o 17:57 Mark Lacey <mark.lacey@apple.com> napisał(a):

On Mar 23, 2017, at 1:58 AM, piotr gorzelany <piotr.gorzelany@gmail.com> 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

<unknown>: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 <david@hartbit.com> 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 ‘<invalid loc>’ rather than the file/line/column info.

Mark

>
> Regards,
> Rien.
>
>
>>
>> On 23 Mar 2017, at 08:11, Rien via swift-users <swift-users@swift.org> wrote:
>>
>>> Thanks for that link, used it to track down the worst compile time offender:
>>>
>>> This piece of code:
>>>
>>> public func logAddrInfoIPAddresses(_ infoPtr: UnsafeMutablePointer<addrinfo>) -> String {
>>>
>>> let addrInfoNil: UnsafeMutablePointer<addrinfo>? = nil
>>> var count: Int = 0
>>> var info: UnsafeMutablePointer<addrinfo> = 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<addrinfo>) -> String {
>>>
>>> let addrInfoNil: UnsafeMutablePointer<addrinfo>? = nil
>>> var count: Int = 0
>>> var info: UnsafeMutablePointer<addrinfo> = 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: Balancingrock (Rien) · GitHub
>>> 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 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
>>>> Profiling your Swift compilation times · Bryan Irace
>>>>
>>>>
>>>> --
>>>> Greg Parker gparker@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
> 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

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

[pgorzelany (Piotr Gorzelany)]

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 <jon@jonshier.com> 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 <swift-users@swift.org>
w dniu 23.03.2017, o godz. 18:06:

On Mar 23, 2017, at 10:02 AM, piotr gorzelany <piotr.gorzelany@gmail.com> > 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 Swift.org - Download Swift as well as the more
recent Xcode 8.3 betas have it.

Mark

W dniu czw., 23.03.2017 o 17:57 Mark Lacey <mark.lacey@apple.com>
napisał(a):

On Mar 23, 2017, at 1:58 AM, piotr gorzelany <piotr.gorzelany@gmail.com> > 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

<unknown>: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 <david@hartbit.com> 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 ‘<invalid loc>’ rather than the
file/line/column info.

Mark

>
> Regards,
> Rien.
>
>
>>
>> On 23 Mar 2017, at 08:11, Rien via swift-users <swift-users@swift.org> > wrote:
>>
>>> Thanks for that link, used it to track down the worst compile time
offender:
>>>
>>> This piece of code:
>>>
>>> public func logAddrInfoIPAddresses(_ infoPtr:
UnsafeMutablePointer<addrinfo>) -> String {
>>>
>>> let addrInfoNil: UnsafeMutablePointer<addrinfo>? = nil
>>> var count: Int = 0
>>> var info: UnsafeMutablePointer<addrinfo> = 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<addrinfo>) -> String {
>>>
>>> let addrInfoNil: UnsafeMutablePointer<addrinfo>? = nil
>>> var count: Int = 0
>>> var info: UnsafeMutablePointer<addrinfo> = 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: Balancingrock (Rien) · GitHub
>>> 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 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
>>>> Profiling your Swift compilation times · Bryan Irace
>>>>
>>>>
>>>> --
>>>> Greg Parker gparker@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
> 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

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

[strike (V T)]

Sadly there is no progress using Swift 5.
That's very disappointing. I want to develop a statistical library that uses generics. -> impossible. Build time exceeds any imagination.