> On May 7, 2016, at 10:39 AM, Austin Zheng via swift-users > <swift-users@swift.org> 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 > > 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.
This definitely strikes me as a problem. The String<T>(_:) constructor is very easy to call by accident if you're trying to hit another unlabeled initializer. It also strikes me as not particularly "value-preserving", since stringifying many types loses information. Perhaps we should propose giving it a label, String(printing:) maybe? -Joe _______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
