[SR-7136] Fast-path ad-hoc printing of Strings

[jckarter]

Previous ID	SR-7136
Radar	None
Original Reporter	@jckarter
Type	Bug

Attachment: Download

Additional Detail from JIRA

Votes	0
Component/s	Standard Library
Labels	Bug, StarterBug
Assignee	None
Priority	Medium

md5: 2686733126be82154b524085fb9de797

Issue Description:

Using Strings with print, string interpolation, String(describing:), etc., is extremely common, but goes through the generic protocol testing dispatch mechanism everything does. We should dynamically check whether something is a String and just print the string.

[jckarter]

Starter bug potential implementation: Look for _print_unlocked in the standard library, and add an early `if let string = value as? String` path.

[swift-ci]

Comment by Yuki Kuroda (JIRA)

I tried this issue with this PR.

[milseman]

@jckarter darquro (JIRA User) do you have code observing this slowdown? Can we add it to our regression benchmarks?

[jckarter]

@nicklockwood observed on Twitter that string interpolation was 100x slower than append()-ing:

https://twitter.com/nicklockwood/status/971506873387143168

Maybe he can share his microbenchmark?

[nicklockwood]

Sorry everyone, it turns out I'm an idiot. I was comparing

foo = "(foo)bar"

against

foo += "bar"

and not

foo = foo + "bar"

which of course is not a fair comparison since the former is updating in place, and the latter is copying the buffer each time.

I re-ran the benchmark and found that interpolation is almost identical to using +.

I did, however discover that foo.appending(bar) is significantly slower than foo + bar, so maybe there's something worth investigating there?

Benchmark: https://gist.github.com/nicklockwood/9a5b846f9535c1f1e5743429a9ccd71f

My results:

[jckarter]

Thanks for following up @nicklockwood! I wonder whether the difference in `+` and `appending` comes down to the difference in their calling conventions, since as currently implemented Swift will pass regular function arguments at +1 and 'self' at +0. Both operations would be strong candidates for passing at +1 when we add keywords for controlling the calling convention, since it would be useful for both functions to do an in-place append when one of the arguments is passed in the unique reference to a buffer.

[milseman]

How does +1 improve things here? For Array, you have the chance to become the last use of a non-trivial single-element append. But with String, you're always copying the underlying code units, which are trivial.

[jckarter]

I suppose it has the most benefit for only the left hand side of the append, since you can do a \+= instead of a \+ and avoid quadratically moving any memory on the left-hand side. There wouldn't be much benefit to consuming the rhs, you're right.

[milseman]

Also, the standard library doesn't implement `appending` for String. You're getting the one from https://github.com/apple/swift/blob/master/stdlib/public/SDK/Foundation/NSStringAPI.swift#L1011, where the Foundation overlay implements something with a bunch of potential bridging and copying back and forth.

These should really be reconciled into some kind of consistent story, ala https://forums.swift.org/t/rfd-reconciling-nsstring-and-string/10350

CC Lance (JIRA User)

edit: grammar and CC

[Moximillian]

The simple appending case for String could be improved just by providing specific extension... Although the example below is probably not the best way to do it.

extension String {

public func appending(_ aString: String) -> String {

var s = self

s.append(aString)

return s

}

}