[swift-users] Improving compilation times?

piotr gorzelany piotr.gorzelany at gmail.com
Thu Mar 23 12:02:01 CDT 2017 

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 at apple.com>
napisał(a):

> On Mar 23, 2017, at 1:58 AM, piotr gorzelany <piotr.gorzelany at 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 at swift.org> napisał:
>
>
> > On Mar 23, 2017, at 12:32 AM, Rien via swift-users <
> swift-users at swift.org> wrote:
> >
> >
> >> On 23 Mar 2017, at 08:27, David Hart <david at 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 at 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: http://github.com/Balancingrock
> >>> Project: http://swiftfire.nl
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>> On 22 Mar 2017, at 23:41, Greg Parker via swift-users <
> swift-users at swift.org> wrote:
> >>>>
> >>>>>
> >>>>> On Mar 22, 2017, at 1:03 PM, piotr gorzelany via swift-users <
> swift-users at 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
> >>>> http://irace.me/swift-profiling
> >>>>
> >>>>
> >>>> --
> >>>> Greg Parker     gparker at apple.com     Runtime Wrangler
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> swift-users mailing list
> >>>> swift-users at swift.org
> >>>> https://lists.swift.org/mailman/listinfo/swift-users
> >>>
> >>> _______________________________________________
> >>> swift-users mailing list
> >>> swift-users at swift.org
> >>> https://lists.swift.org/mailman/listinfo/swift-users
> >
> > _______________________________________________
> > swift-users mailing list
> > swift-users at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-users
>
> _______________________________________________
> swift-users mailing list
> swift-users at swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20170323/5d63af18/attachment.html>

More information about the swift-users mailing list