Hi Austin,
I further “swiftyfied” the code to this
(swift-DEVELOPMENT-SNAPSHOT-2016-05-03-a):
import Foundation
let N = 1_000_000
func generateTestData() -> [String] {
return (0..<N).map { _ in ",,abc, 123 ,x, , more more more,\u{A0}and yet
more, " }
}
func splitAndTrim(s: String, sep: Character) -> [String] {
return s.characters.split(separator: sep, omittingEmptySubsequences: false)
.map(String.init)
.map { $0.trimmingCharacters(in:
.whitespacesAndNewlines()) }
}
func doSplits(data: [String]) -> Int {
return data.reduce(0) { $0 + splitAndTrim(s: $1, sep: Character(",")).count }
}
let data = generateTestData()
let start = NSDate()
let sum = doSplits(data: data)
print("elapsed: \(NSDate().timeIntervalSince(start))")
print("sum: \(sum)")
I didn’t expect it to run as fast as the original (or even faster) but the code
above takes 13 seconds to run… But that’s just an aside :)
To actually come back to the problem you mentioned:
You can disambiguate the initializer to call in the following ways (probably
there are other ways):
Add an ! after the init call since the one which should be used is failable
(the one that uses reflection does not), so the compiler chooses the “right”
one.
result.append(begin == eos ? "" : String(cs[begin..<end.successor()])!)
Or you can reference the initializer and use it afterwards (more future-proof):
let utf16View = cs[begin..<end.successor()]
let initializer = String.init as (String.UTF16View -> String?)
result.append(begin == eos ? "" : initializer(utf16View)!)
This reduces the time to 2.2 seconds on my machine (from ~2.9), but that’s
still far from 0.8.
> What do other people think? Is this something worth worrying about, or is it
> so rare that it shouldn't matter? Also, any suggestions as to how that code
> sample might be improved would be appreciated - my naive first attempt wasn't
> any better.
It might be very surprising behavior and we could think about adding an
external label to all those initializers that cause trouble. The performance is
of course a little worrying for a zero-cost abstractions language, but I think
there are currently more important goals (getting the design right, etc.). We
are still at the early stages with a lot of stuff changing and I think when the
syntax, ABI, etc. are settled, performance / optimization will get more
attention :)
- Dennis
> On May 7, 2016, at 7:39 PM, Austin Zheng via swift-users
> <[email protected]> wrote:
>
> Hello Swift users,
>
> I wanted to run something past you folks and get some opinions/feedback.
>
> About a month ago on Hacker News I saw someone commenting about how Swift's
> string-handling code was unbearably slow (3 seconds to run a code sample, vs.
> 0.8 in Java). I asked him to provide the code, and he obliged. Unfortunately,
> I didn't have time to dig into it until this morning. The code in its
> entirety can be found here:
> https://gist.github.com/austinzheng/d6c674780a58cb63832c4df3f809e683
> <https://gist.github.com/austinzheng/d6c674780a58cb63832c4df3f809e683>
>
> At line 26 we have the following code:
>
> result.append(begin == eos ? "" : String(cs[begin..<end.successor()]))
>
> 'cs' is a UTF16 view into an input string, while 'result' is a [String]. When
> I profiled the code in Instruments, I noticed that it was spending
> significant time within the reflection machinery.
>
> It turns out that the initializer to make a String out of a utf16 view looks
> like this, and I believe this is the initializer the author intended to call:
>
> init?(_: String.UTF16View) <>
>
> However, the actual initializer being called was this String initializer in
> the Mirror code:
>
> public init<Subject>(_ instance: Subject)
>
> This seems like a tricky gotcha for developers who aren't extremely familiar
> with both the String and reflection APIs. His code looked reasonable at a
> first glance and I didn't suspect anything was wrong until I profiled it.
> Even so, I only made the connection because I recognized the name of the
> standard library function from poking around inside the source files.
>
> What do other people think? Is this something worth worrying about, or is it
> so rare that it shouldn't matter? Also, any suggestions as to how that code
> sample might be improved would be appreciated - my naive first attempt wasn't
> any better.
>
> Best,
> Austin
>
>
> _______________________________________________
> swift-users mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-users
_______________________________________________
swift-users mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-users
