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 >> <mailto: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 > <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 >> <mailto:mark.la...@apple.com>> napisał(a): >>> On Mar 23, 2017, at 1:58 AM, piotr gorzelany <piotr.gorzel...@gmail.com >>> <mailto: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 <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 <da...@hartbit.com >>> >> <mailto: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 >>> >> <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/> >>> >>> Blog: http://swiftrien.blogspot.com <http://swiftrien.blogspot.com/> >>> >>> Github: http://github.com/Balancingrock >>> >>> <http://github.com/Balancingrock> >>> >>> Project: http://swiftfire.nl <http://swiftfire.nl/> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>> 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 >>> >>>> http://irace.me/swift-profiling <http://irace.me/swift-profiling> >>> >>>> >>> >>>> >>> >>>> -- >>> >>>> Greg Parker gpar...@apple.com <mailto:gpar...@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 >>> >>>> <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 >>> >>> <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 >>> > <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 >>> <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
