[swift-server-dev] HTTPMethod, was: Re: Next HTTP API meeting

Michael Gottesman mgottesman at apple.com
Thu Mar 23 13:59:28 CDT 2017


> On Mar 23, 2017, at 7:49 AM, Helge Heß via swift-server-dev <swift-server-dev at swift.org> wrote:
> 
> On 23 Mar 2017, at 15:39, Alex Blewitt <alblue at apple.com> wrote:
>>> On 23 Mar 2017, at 13:50, Helge Heß via swift-server-dev <swift-server-dev at swift.org> wrote:
>>> 
>>> P.S.: Does Swift 4 propose any way to intern strings? That is also a nice way to do this kind of thing and still get decent performance (essentially what Cocoa Swift does for NSNotification names).
>> 
>> Interning only makes sense for reference types, and Swift's String is a value type.
> 
> The public interface of String is a value type, its internal representation could still be a reference to shared state. I thought that is already the way it works (to allow for CoW and to avoid copying when just references are passed) - or is this only for Dictionary/Array? In such a scenario interning *would* make sense.
> 
> The point is that this would reduce the overhead of using Strings in the API (e.g. if the parser would intern the header names, we wouldn’t have the create copies all the time …).
> 
> But maybe it is not strictly necessary and the parser API could provide a
> 
>  struct HeaderFields {
>    static let contentType = “content-type"
>  }
> 
> and pass out such. If user-level code would then compare parsed headers against HeaderFields.contentType, it would avoid the string matching and just compare the internal reference?

Just an FYI, for pure ASCII constant strings, a special constant internal string representation is used. See: String.swift:420. I am not sure if there is support for just comparing the internal reference though.

> 
> hh
> 
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev



More information about the swift-server-dev mailing list