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