HTTP Parser

I would like to provide some additional detail to the discussion on November 4 (which I missed since I joined recently).

The team pointed out this thread in Kitura which I initially opened:

https://github.com/IBM-Swift/Kitura-net/issues/52

Here is the referenced Swift http_parser project which I initially ported as a thought experiment. The goals, API and performance are described in the readme.

Michael Gottesman from Apple (@gottesmm) contacted me 2 weeks ago to see if we could add the project into the Swift Benchmark Suite. See the bottom of this PR for the request:

https://github.com/IBM-Swift/Kitura-net/pull/55

Michael and I approached the Node.js Foundation to see if they were willing to dual license http_parser under Apache 2 so it would be compatible with the Swift license. Here is that discussion, but in summary, a dual license is not realistic.

https://github.com/nodejs/http-parser/issues/344

So, a http_parser Swift port:

- Would not have the proper license to be included in Swift

- Does not take full advantage of Swift

- Has the issues previously pointed out (UnsafePointers, asserts, throws simulating gotos)

- Does, however, demonstrate a Swift HTTP parser performance of 500K requests per second

Looking forward to meeting everyone on our call tomorrow. Hopefully this detail was helpful.

Dave Sperling

Smith Micro

Hi Dave,

thanks for your post, this detail is indeed quite helpful.

I don’t think anyone seriously suggested using a Swift port of the http_parser but instead just the upstream C one. But it sounds like MIT licensed code can’t be used as part of the effort, maybe that should be added the the front-page of the effort.

I assume it is not a huge issue though as a libhttp_parser can be shipped separately from Swift itself, similar to what you would do for OpenSSL etc (and what is already being done with libcurl on Linux).

In any case: Whatever is decided, it at least establishes a performance characteristic, I think any replacement should accomplish a comparable one - preferably faster of course :-)

hh

···

On 20 Nov 2016, at 16:58, David Sperling via swift-server-dev <swift-server-dev@swift.org> wrote:

I would like to provide some additional detail to the discussion on November 4 (which I missed since I joined recently).

The team pointed out this thread in Kitura which I initially opened:
Swap HTTPParser Swift package for http-parser · Issue #52 · Kitura/Kitura-net · GitHub

Here is the referenced Swift http_parser project which I initially ported as a thought experiment. The goals, API and performance are described in the readme.
GitHub - smithmicro/HTTPParser: HTTP request/response parser for Swift 3

Michael Gottesman from Apple (@gottesmm) contacted me 2 weeks ago to see if we could add the project into the Swift Benchmark Suite. See the bottom of this PR for the request:
Swap HTTPParser Swift package for http-parser - issue #52 by dsperling · Pull Request #55 · Kitura/Kitura-net · GitHub

Michael and I approached the Node.js Foundation to see if they were willing to dual license http_parser under Apache 2 so it would be compatible with the Swift license. Here is that discussion, but in summary, a dual license is not realistic.
Swift Port - request for OSS License modification · Issue #344 · nodejs/http-parser · GitHub

So, a http_parser Swift port:
- Would not have the proper license to be included in Swift
- Does not take full advantage of Swift
- Has the issues previously pointed out (UnsafePointers, asserts, throws simulating gotos)
- Does, however, demonstrate a Swift HTTP parser performance of 500K requests per second

Looking forward to meeting everyone on our call tomorrow. Hopefully this detail was helpful.

Dave Sperling
Smith Micro

But it sounds like MIT licensed code can’t be used as part of the

effort, maybe that should be added the the front-page of the effort.

I'm not 100% convinced this is true. There's nothing (legally) preventing
the inclusion of MIT licensed code in a Apache 2.0 licensed product, you
just may have to list some Product Unique Terms (PUTs) to cover it - we
don't need the Node.js community to dual-license it for us to use it.
Parts of the Swift toolchain already have compiled-in dependencies on MIT
licensed code, so my guess is that ship has already sailed on using
non-Apache 2.0 licensed code.

Having said that, we'd obviously need a read and approval from the Swift
Core Team (and Apple legal!) before making a compiled-in dependency on
anything.

Chris

···

From: Helge Heß via swift-server-dev <swift-server-dev@swift.org>
To: "swift-server-dev@swift.org" <swift-server-dev@swift.org>
Date: 20/11/2016 18:08
Subject: Re: [swift-server-dev] HTTP Parser
Sent by: swift-server-dev-bounces@swift.org

Hi Dave,

thanks for your post, this detail is indeed quite helpful.

I don’t think anyone seriously suggested using a Swift port of the
http_parser but instead just the upstream C one. But it sounds like MIT
licensed code can’t be used as part of the effort, maybe that should be
added the the front-page of the effort.

I assume it is not a huge issue though as a libhttp_parser can be shipped
separately from Swift itself, similar to what you would do for OpenSSL etc
(and what is already being done with libcurl on Linux).

In any case: Whatever is decided, it at least establishes a performance
characteristic, I think any replacement should accomplish a comparable one
- preferably faster of course :-)

hh

On 20 Nov 2016, at 16:58, David Sperling via swift-server-dev <swift-server-dev@swift.org> wrote:

I would like to provide some additional detail to the discussion on

November 4 (which I missed since I joined recently).

The team pointed out this thread in Kitura which I initially opened:
Swap HTTPParser Swift package for http-parser · Issue #52 · Kitura/Kitura-net · GitHub

Here is the referenced Swift http_parser project which I initially

ported as a thought experiment. The goals, API and performance are
described in the readme.

GitHub - smithmicro/HTTPParser: HTTP request/response parser for Swift 3

Michael Gottesman from Apple (@gottesmm) contacted me 2 weeks ago to see

if we could add the project into the Swift Benchmark Suite. See the
bottom of this PR for the request:

Swap HTTPParser Swift package for http-parser - issue #52 by dsperling · Pull Request #55 · Kitura/Kitura-net · GitHub

Michael and I approached the Node.js Foundation to see if they were

willing to dual license http_parser under Apache 2 so it would be
compatible with the Swift license. Here is that discussion, but in
summary, a dual license is not realistic.

Swift Port - request for OSS License modification · Issue #344 · nodejs/http-parser · GitHub

So, a http_parser Swift port:
- Would not have the proper license to be included in Swift
- Does not take full advantage of Swift
- Has the issues previously pointed out (UnsafePointers, asserts, throws

simulating gotos)

- Does, however, demonstrate a Swift HTTP parser performance of 500K

requests per second

Looking forward to meeting everyone on our call tomorrow. Hopefully

this detail was helpful.

Dave Sperling
Smith Micro

_______________________________________________
swift-server-dev mailing list
swift-server-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-server-dev

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

>> But it sounds like MIT licensed code can’t be used as part of the effort, maybe that should be added the the front-page of the effort.

I'm not 100% convinced this is true. There's nothing (legally) preventing the inclusion of MIT licensed code in a Apache 2.0 licensed product, you just may have to list some Product Unique Terms (PUTs) to cover it - we don't need the Node.js community to dual-license it for us to use it. Parts of the Swift toolchain already have compiled-in dependencies on MIT licensed code, so my guess is that ship has already sailed on using non-Apache 2.0 licensed code.

Having said that, we'd obviously need a read and approval from the Swift Core Team (and Apple legal!) before making a compiled-in dependency on anything.

We want a consistent license over the entire code base. I imagine we will make an external test suite that will be in a different repository so this will not be an issue.

Originally we put the swift perf test suite in the swift tree since people kept on breaking it. Since we use PR testing this is no longer an issue (the benchmarks are built as apart of the PR testing). There are some questions around how this is done/who is it done by/when is it down, that will need to be answered before I can move forward with this.

Michael

···

On Nov 21, 2016, at 5:55 AM, Chris Bailey via swift-server-dev <swift-server-dev@swift.org> wrote:

Chris

From: Helge Heß via swift-server-dev <swift-server-dev@swift.org>
To: "swift-server-dev@swift.org" <swift-server-dev@swift.org>
Date: 20/11/2016 18:08
Subject: Re: [swift-server-dev] HTTP Parser
Sent by: swift-server-dev-bounces@swift.org

Hi Dave,

thanks for your post, this detail is indeed quite helpful.

I don’t think anyone seriously suggested using a Swift port of the http_parser but instead just the upstream C one. But it sounds like MIT licensed code can’t be used as part of the effort, maybe that should be added the the front-page of the effort.

I assume it is not a huge issue though as a libhttp_parser can be shipped separately from Swift itself, similar to what you would do for OpenSSL etc (and what is already being done with libcurl on Linux).

In any case: Whatever is decided, it at least establishes a performance characteristic, I think any replacement should accomplish a comparable one - preferably faster of course :-)

hh

> On 20 Nov 2016, at 16:58, David Sperling via swift-server-dev <swift-server-dev@swift.org> wrote:
>
> I would like to provide some additional detail to the discussion on November 4 (which I missed since I joined recently).
>
> The team pointed out this thread in Kitura which I initially opened:
> Swap HTTPParser Swift package for http-parser · Issue #52 · Kitura/Kitura-net · GitHub
>
> Here is the referenced Swift http_parser project which I initially ported as a thought experiment. The goals, API and performance are described in the readme.
> GitHub - smithmicro/HTTPParser: HTTP request/response parser for Swift 3
>
> Michael Gottesman from Apple (@gottesmm) contacted me 2 weeks ago to see if we could add the project into the Swift Benchmark Suite. See the bottom of this PR for the request:
> Swap HTTPParser Swift package for http-parser - issue #52 by dsperling · Pull Request #55 · Kitura/Kitura-net · GitHub
>
> Michael and I approached the Node.js Foundation to see if they were willing to dual license http_parser under Apache 2 so it would be compatible with the Swift license. Here is that discussion, but in summary, a dual license is not realistic.
> Swift Port - request for OSS License modification · Issue #344 · nodejs/http-parser · GitHub
>
> So, a http_parser Swift port:
> - Would not have the proper license to be included in Swift
> - Does not take full advantage of Swift
> - Has the issues previously pointed out (UnsafePointers, asserts, throws simulating gotos)
> - Does, however, demonstrate a Swift HTTP parser performance of 500K requests per second
>
>
> Looking forward to meeting everyone on our call tomorrow. Hopefully this detail was helpful.
>
>
> Dave Sperling
> Smith Micro

_______________________________________________
swift-server-dev mailing list
swift-server-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-server-dev

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
_______________________________________________
swift-server-dev mailing list
swift-server-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-server-dev

This obviously makes a lot of sense but only partially affects the choice here. There is no need to actually embed the source code (though that w/o question would be the more convenient option, specifically on Darwin).

hh

···

On 22 Nov 2016, at 00:38, Michael Gottesman <mgottesman@apple.com> wrote:

We want a consistent license over the entire code base.

Here are the steps for those that want to review the performance of HTTPParser.

  * git clone GitHub - smithmicro/HTTPParser: HTTP request/response parser for Swift 3
  * in the directory, run “swift package generate-xcodeproj”
  * open HTTPParser.xcodeproj in Xcode 8.1
  * Select “bench” from the target dropdown list
  * Select Profile from the Product menu
  * Choose Time Profiler, then record

Attached is a screenshot showing 5.5% being spent in swift_release, and 2.7% percent in swift_bridgeObjectRetain.

I will be interesting to try the suggestions that Helge has pointed out here:

Dave

P.S. If you want to just run the program in Xcode to see the performance, switch to Release build configuration.

[cid:image001.png@01D2456F.20C20BC0]

···

From: <swift-server-dev-bounces@swift.org> on behalf of Michael Gottesman via swift-server-dev <swift-server-dev@swift.org>
Reply-To: Michael Gottesman <mgottesman@apple.com>
Date: Monday, November 21, 2016 at 3:38 PM
To: Chris Bailey <BAILEYC@uk.ibm.com>
Cc: "swift-server-dev@swift.org" <swift-server-dev@swift.org>
Subject: Re: [swift-server-dev] HTTP Parser

On Nov 21, 2016, at 5:55 AM, Chris Bailey via swift-server-dev <swift-server-dev@swift.org<mailto:swift-server-dev@swift.org>> wrote:

But it sounds like MIT licensed code can’t be used as part of the effort, maybe that should be added the the front-page of the effort.

I'm not 100% convinced this is true. There's nothing (legally) preventing the inclusion of MIT licensed code in a Apache 2.0 licensed product, you just may have to list some Product Unique Terms (PUTs) to cover it - we don't need the Node.js community to dual-license it for us to use it. Parts of the Swift toolchain already have compiled-in dependencies on MIT licensed code, so my guess is that ship has already sailed on using non-Apache 2.0 licensed code.

Having said that, we'd obviously need a read and approval from the Swift Core Team (and Apple legal!) before making a compiled-in dependency on anything.

We want a consistent license over the entire code base. I imagine we will make an external test suite that will be in a different repository so this will not be an issue.

Originally we put the swift perf test suite in the swift tree since people kept on breaking it. Since we use PR testing this is no longer an issue (the benchmarks are built as apart of the PR testing). There are some questions around how this is done/who is it done by/when is it down, that will need to be answered before I can move forward with this.

Michael

Chris

From: Helge Heß via swift-server-dev <swift-server-dev@swift.org<mailto:swift-server-dev@swift.org>>
To: "swift-server-dev@swift.org<mailto:swift-server-dev@swift.org>" <swift-server-dev@swift.org<mailto:swift-server-dev@swift.org>>
Date: 20/11/2016 18:08
Subject: Re: [swift-server-dev] HTTP Parser
Sent by: swift-server-dev-bounces@swift.org<mailto:swift-server-dev-bounces@swift.org>
________________________________

Hi Dave,

thanks for your post, this detail is indeed quite helpful.

I don’t think anyone seriously suggested using a Swift port of the http_parser but instead just the upstream C one. But it sounds like MIT licensed code can’t be used as part of the effort, maybe that should be added the the front-page of the effort.

I assume it is not a huge issue though as a libhttp_parser can be shipped separately from Swift itself, similar to what you would do for OpenSSL etc (and what is already being done with libcurl on Linux).

In any case: Whatever is decided, it at least establishes a performance characteristic, I think any replacement should accomplish a comparable one - preferably faster of course :-)

hh

On 20 Nov 2016, at 16:58, David Sperling via swift-server-dev <swift-server-dev@swift.org<mailto:swift-server-dev@swift.org>> wrote:

I would like to provide some additional detail to the discussion on November 4 (which I missed since I joined recently).

The team pointed out this thread in Kitura which I initially opened:
Swap HTTPParser Swift package for http-parser · Issue #52 · Kitura/Kitura-net · GitHub

Here is the referenced Swift http_parser project which I initially ported as a thought experiment. The goals, API and performance are described in the readme.
GitHub - smithmicro/HTTPParser: HTTP request/response parser for Swift 3

Michael Gottesman from Apple (@gottesmm) contacted me 2 weeks ago to see if we could add the project into the Swift Benchmark Suite. See the bottom of this PR for the request:
Swap HTTPParser Swift package for http-parser - issue #52 by dsperling · Pull Request #55 · Kitura/Kitura-net · GitHub

Michael and I approached the Node.js Foundation to see if they were willing to dual license http_parser under Apache 2 so it would be compatible with the Swift license. Here is that discussion, but in summary, a dual license is not realistic.
Swift Port - request for OSS License modification · Issue #344 · nodejs/http-parser · GitHub

So, a http_parser Swift port:
- Would not have the proper license to be included in Swift
- Does not take full advantage of Swift
- Has the issues previously pointed out (UnsafePointers, asserts, throws simulating gotos)
- Does, however, demonstrate a Swift HTTP parser performance of 500K requests per second

Looking forward to meeting everyone on our call tomorrow. Hopefully this detail was helpful.

Dave Sperling
Smith Micro

_______________________________________________
swift-server-dev mailing list
swift-server-dev@swift.org<mailto:swift-server-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-server-dev

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
_______________________________________________
swift-server-dev mailing list
swift-server-dev@swift.org<mailto:swift-server-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-server-dev

Hi all,

Sorry I didn't have much time and therefore could only do a mostly search and replace mess [1].
I think I eliminated most retain/releases. I'm not sure if it actually works but the benchmark produces a number and the tests are happy. But I'd be very worry about it actually working! Seriously if anyone considers using it, please review the code. I have just tried to improve it pretty much mechanically. I haven't actually fully read the code.

But before (on my machine)
--- SNIP ---
$ .build/release/bench
Benchmark result:
Took 7.7 seconds to run
648582.28 req/sec
--- SNAP ---

after
--- SNIP ---
$ .build/release/bench
Benchmark result:
Took 5.27 seconds to run
948171.8 req/sec
--- SNAP ---

which is almost 50% more reqs/s.

- The reason there was plenty of ref counting done is that it used to use classes. I changed everything to structs (inout where necessary) and also switched from String to StaticString.
- it also used protocols as types like 'func foo(x: SomeProtocl)' that always comes with a protocol witness table which is bad for performance too
- I also eliminated copies of values that aren't necessary.
- I think generally it's now much more inline with the C version

Any questions please let me know. The full diff can be found here [1].

And again, I'm not saying I turned this into great Swift or anything. It's just meant as a demonstration that you can get rid of the reference counting overhead if you switch to value types. If you need reference semantics but don't want to pay the reference counting overhead I guess UnsafePointer<> and friend work which obviously comes with some drawbacks.

All in all I don't see much value in translating the C version to Swift. The C version gets updated, the Swift version then constantly needs to replicate these changes. And given that Swift has excellent C calling capabilities, why not just stick to the C version?

[1]: DO NOT MERGE: less ref counting by weissi · Pull Request #1 · smithmicro/HTTPParser · GitHub

Cheers,
  Johannes

···

On 23 Nov 2016, at 17:51, David Sperling via swift-server-dev <swift-server-dev@swift.org> wrote:

Here are the steps for those that want to review the performance of HTTPParser.

  • git clone GitHub - smithmicro/HTTPParser: HTTP request/response parser for Swift 3
  • in the directory, run “swift package generate-xcodeproj”
  • open HTTPParser.xcodeproj in Xcode 8.1
  • Select “bench” from the target dropdown list
  • Select Profile from the Product menu
  • Choose Time Profiler, then record

Attached is a screenshot showing 5.5% being spent in swift_release, and 2.7% percent in swift_bridgeObjectRetain.

I will be interesting to try the suggestions that Helge has pointed out here:
Update with meeting minutes by seabaylea · Pull Request #52 · swift-server/work-group · GitHub

Dave

P.S. If you want to just run the program in Xcode to see the performance, switch to Release build configuration.

<image001.png>

From: <swift-server-dev-bounces@swift.org> on behalf of Michael Gottesman via swift-server-dev <swift-server-dev@swift.org>
Reply-To: Michael Gottesman <mgottesman@apple.com>
Date: Monday, November 21, 2016 at 3:38 PM
To: Chris Bailey <BAILEYC@uk.ibm.com>
Cc: "swift-server-dev@swift.org" <swift-server-dev@swift.org>
Subject: Re: [swift-server-dev] HTTP Parser

On Nov 21, 2016, at 5:55 AM, Chris Bailey via swift-server-dev <swift-server-dev@swift.org> wrote:

>> But it sounds like MIT licensed code can’t be used as part of the effort, maybe that should be added the the front-page of the effort.

I'm not 100% convinced this is true. There's nothing (legally) preventing the inclusion of MIT licensed code in a Apache 2.0 licensed product, you just may have to list some Product Unique Terms (PUTs) to cover it - we don't need the Node.js community to dual-license it for us to use it. Parts of the Swift toolchain already have compiled-in dependencies on MIT licensed code, so my guess is that ship has already sailed on using non-Apache 2.0 licensed code.

Having said that, we'd obviously need a read and approval from the Swift Core Team (and Apple legal!) before making a compiled-in dependency on anything.

We want a consistent license over the entire code base. I imagine we will make an external test suite that will be in a different repository so this will not be an issue.

Originally we put the swift perf test suite in the swift tree since people kept on breaking it. Since we use PR testing this is no longer an issue (the benchmarks are built as apart of the PR testing). There are some questions around how this is done/who is it done by/when is it down, that will need to be answered before I can move forward with this.

Michael

Chris

From: Helge Heß via swift-server-dev <swift-server-dev@swift.org>
To: "swift-server-dev@swift.org" <swift-server-dev@swift.org>
Date: 20/11/2016 18:08
Subject: Re: [swift-server-dev] HTTP Parser
Sent by: swift-server-dev-bounces@swift.org

Hi Dave,

thanks for your post, this detail is indeed quite helpful.

I don’t think anyone seriously suggested using a Swift port of the http_parser but instead just the upstream C one. But it sounds like MIT licensed code can’t be used as part of the effort, maybe that should be added the the front-page of the effort.

I assume it is not a huge issue though as a libhttp_parser can be shipped separately from Swift itself, similar to what you would do for OpenSSL etc (and what is already being done with libcurl on Linux).

In any case: Whatever is decided, it at least establishes a performance characteristic, I think any replacement should accomplish a comparable one - preferably faster of course :-)

hh

> On 20 Nov 2016, at 16:58, David Sperling via swift-server-dev <swift-server-dev@swift.org> wrote:
>
> I would like to provide some additional detail to the discussion on November 4 (which I missed since I joined recently).
>
> The team pointed out this thread in Kitura which I initially opened:
> Swap HTTPParser Swift package for http-parser · Issue #52 · Kitura/Kitura-net · GitHub
>
> Here is the referenced Swift http_parser project which I initially ported as a thought experiment. The goals, API and performance are described in the readme.
> GitHub - smithmicro/HTTPParser: HTTP request/response parser for Swift 3
>
> Michael Gottesman from Apple (@gottesmm) contacted me 2 weeks ago to see if we could add the project into the Swift Benchmark Suite. See the bottom of this PR for the request:
> Swap HTTPParser Swift package for http-parser - issue #52 by dsperling · Pull Request #55 · Kitura/Kitura-net · GitHub
>
> Michael and I approached the Node.js Foundation to see if they were willing to dual license http_parser under Apache 2 so it would be compatible with the Swift license. Here is that discussion, but in summary, a dual license is not realistic.
> Swift Port - request for OSS License modification · Issue #344 · nodejs/http-parser · GitHub
>
> So, a http_parser Swift port:
> - Would not have the proper license to be included in Swift
> - Does not take full advantage of Swift
> - Has the issues previously pointed out (UnsafePointers, asserts, throws simulating gotos)
> - Does, however, demonstrate a Swift HTTP parser performance of 500K requests per second
>
>
> Looking forward to meeting everyone on our call tomorrow. Hopefully this detail was helpful.
>
>
> Dave Sperling
> Smith Micro

_______________________________________________
swift-server-dev mailing list
swift-server-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-server-dev

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
_______________________________________________
swift-server-dev mailing list
swift-server-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-server-dev

_______________________________________________
swift-server-dev mailing list
swift-server-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-server-dev