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