> On 23 Mar 2017, at 10:27, Rien <r...@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: http://github.com/Balancingrock > Project: http://swiftfire.nl > > > > > >> On 23 Mar 2017, at 09:58, 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? >> >> 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
