[SR-7602] UTF8 should be (one of) the fastest String encoding(s)

[weissi]

Previous ID	SR-7602
Radar	None
Original Reporter	@weissi
Type	Bug
Status	Resolved
Resolution	Done

Additional Detail from JIRA

Votes	26
Component/s	Standard Library
Labels	Bug, AffectsABI
Assignee	@milseman
Priority	Medium

md5: f681e7f0741f98e436f811971add77c3

Sub-Tasks:

• SR-7725 [String] New validity model

Issue Description:

I believe that there are really only one (and a half) encodings that matter today: UTF8 (and its subset ASCII).
Therefore it's important that Swift's fastest String encoding is UTF8.

From what I can tell today the fastest String encodings are UTF16 and ASCII. Everything else will have worse performance.

This also seems to ABI relevant so AFAIK this needs to be fixed very soon.

Requirements:

1. being able to copy UTF-8 encoded bytes from a String into a pre-allocated raw buffer must be allocation-free and as fast as memcpy can copy them

2. creating a String from UTF-8 encoded bytes should just validate the encoding and store the bytes as they are

3. slightly softer but still very strong requirement: currently (even with ASCII) only the stdlib seems to be able to get a pointer to the contiguous ASCII representation (if at all in that form). That works fine if you just want to copy the bytes (UnsafeMutableBufferPointer(start: destinationStart, count: destinationLength).initialize(from: string.utf8) which will use memcpy if in ASCII representation) but doesn't allow you to implement your own algorithms that are only performant on a contiguously stored [UInt8]

[swift-ci]

Comment by tanner0101 (JIRA)

Huge +1 to this.

To give some additional insights here, `String` has been a major burden for us in developing Vapor (server side Swift framework). At this point it's basically forbidden to use String in any internal code and only our public APIs will accept it. We resort to using things like `[UInt8]` and `UnsafeBufferPointer<UInt8>` internally instead.

Still even with our internal optimizations, there is still a lot of friction cross-module and to our end users where `String`s are used.

If `String` were more performant dealing with UTF-8 that would greatly improve the speed of our framework and cleanup a lot of our internal code.

[swift-ci]

Comment by Alex Reilly (JIRA)

+1

[jdmcd]

Server side swift needs this big time. Would love to see this added.

[swift-ci]

Comment by Francisco Rivas (JIRA)

+1

[swift-ci]

Comment by Mikhail Isaev (JIRA)

+1

[swift-ci]

Comment by Anthony Castelli (JIRA)

+1

[swift-ci]

Comment by Damir Stuhec (JIRA)

+1

[tkrajacic]

+2

[swift-ci]

Comment by Petro Rovenskyy (JIRA)

+1

[swift-ci]

Comment by Helge Heß (JIRA)

+1

[swift-ci]

Comment by Lucian Boboc (JIRA)

+1

[belkadan]

cc @milseman

Aside: please stop with the +1 comments. There's a "Vote for this issue" button right over there.

[milseman]

@belkadan +1 😛 . I think this is vital to Swift's long-term health on any platform or domain outside of its current niche (and honestly, even within it).

Thank you for sharing your experience tannernelson (JIRA User). Do you have anything with more detail here, such as how much performance and code bloat is due to this? How does this friction manifest for your users and how could storing UTF-8 without transcoding remove it?

Is anyone else from this thread able to share their experience? Reports like this really help the project to prioritize effectively and push for the right thing.

(As for the fear concerning ABI stability, it's a little complicated and there are degrees to which we can reserve the ability to support this in the future.)

[swift-ci]

Comment by tanner0101 (JIRA)

@milseman Virtually all of it comes down to `String(data: myData, encoding: .utf8)` and `myString.data(encoding: .utf8)`.

When parsing protocols such as HTTP, Redis, MySQL, PostgreSQL, etc we will read data from the OS into an `UnsafeBufferPointer<UInt8>`. This is almost always via NIO's [`ByteBuffer`](https://apple.github.io/swift-nio/docs/current/NIO/Structs/ByteBuffer.html) type. We sometimes grab `String` from that directly or grab `Data` if we want to iterate over the bytes for additional parsing. [Here is an example of common byte buffer usage](https://github.com/vapor/mysql/blob/master/Sources/MySQL/Protocol/MySQLBinaryResultsetRow.swift#L39-L40).

In other words, from `UnsafePointer<UInt8>` we commonly read `FixedWidthInteger`, `BinaryFloatingPoint`, `Data`, and `String`. All are very performant except String which is the concern since the vast majority of bytes ends up being `String`s. Considering the DB use case specifically, the data transfer is usually emails, names, bios, comments, etc. Very few bytes are actually dedicated to binary numbers or data blobs. Strings everywhere.

To summarize, the faster we can get from `Swift.Unsafe...Pointer<UInt8>` or `Foundation.Data` to `String` the better. That will affect (for the better!) quite literally our entire framework.

[weissi]

just to add to tannernelson (JIRA User)'s great comment (thanks!): If the String comes from a ByteBuffer through get/readString(length🙂 then we'll construct it using the stdlib's String decoding mechanism

String(decoding: UnsafeBufferPointer(...), as: UTF8.self)