<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hi all,<br class=""><br class="">Sorry I didn't have much time and therefore could only do a mostly search and replace mess [1].<br class="">I think I eliminated most retain/releases. I'm not sure if it actually works but the benchmark produces a&nbsp;number and the tests are happy. But I'd be very worry about it actually working! Seriously if anyone&nbsp;considers using it, please review the code. I have just tried to improve it pretty much mechanically. I&nbsp;haven't actually fully read the code.<br class=""><br class="">But before (on my machine)<br class="">--- SNIP ---<br class="">$ .build/release/bench<br class="">Benchmark result:<br class="">Took 7.7 seconds to run<br class="">648582.28 req/sec<br class="">--- SNAP ---<br class=""><br class="">after<br class="">--- SNIP ---<br class="">$ .build/release/bench<br class="">Benchmark result:<br class="">Took 5.27 seconds to run<br class="">948171.8 req/sec<br class="">--- SNAP ---<br class=""><br class="">which is almost 50% more reqs/s.<br class=""><br class="">- The reason there was plenty of ref counting done is that it used to use classes. I changed everything to&nbsp;structs (inout where necessary) and also switched from String to StaticString.<br class="">- it also used protocols as types like 'func foo(x: SomeProtocl)' that always comes with a protocol&nbsp;witness table which is bad for performance too<br class="">- I also eliminated copies of values that aren't necessary.<br class="">- I think generally it's now much more inline with the C version<br class=""><br class="">Any questions please let me know. The full diff can be found here [1].<br class=""><br class="">And again, I'm not saying I turned this into great Swift or anything. It's just meant as a demonstration&nbsp;that you can get rid of the reference counting overhead if you switch to value types. If you need&nbsp;reference semantics but don't want to pay the reference counting overhead I guess UnsafePointer&lt;&gt; and&nbsp;friend work which obviously comes with some drawbacks.<br class=""><br class="">All in all I don't see much value in translating the C version to Swift. The C version gets updated, the&nbsp;Swift version then constantly needs to replicate these changes. And given that Swift has excellent C&nbsp;calling capabilities, why not just stick to the C version?<br class=""><br class="">[1]:&nbsp;<a href="https://github.com/smithmicro/HTTPParser/pull/1/files" class="">https://github.com/smithmicro/HTTPParser/pull/1/files</a><br class=""><br class="">Cheers,<br class="">&nbsp; Johannes<div class=""><img apple-inline="yes" id="87502EFE-E892-455E-83FE-5E39FBF32CB4" src="cid:0E370231-3F7A-4A1D-B601-8742826F0012" class=""><br class=""><blockquote type="cite" class="">On 23 Nov 2016, at 17:51, David Sperling via swift-server-dev &lt;swift-server-dev@swift.org&gt; wrote:<br class=""><br class="">Here are the steps for those that want to review the performance of HTTPParser.<br class="">&nbsp;<br class=""><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>• git clone&nbsp;https://github.com/smithmicro/HTTPParser.git<br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>• in the directory, run “swift package generate-xcodeproj”<br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>• open HTTPParser.xcodeproj in Xcode 8.1<br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>• Select “bench” from the target dropdown list<br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>• Select Profile from the Product menu<br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>• Choose Time Profiler, then record<br class=""></div>&nbsp;<br class="">Attached is a screenshot showing 5.5% being spent in swift_release, and 2.7% percent in swift_bridgeObjectRetain.<br class="">&nbsp;<br class="">I will be interesting to try the suggestions that Helge has pointed out here:<br class="">https://github.com/swift-server/work-group/pull/52<br class="">&nbsp;<br class="">Dave<br class="">&nbsp;<br class="">P.S. &nbsp;If you want to just run the program in Xcode to see the performance, switch to Release build configuration.<br class="">&nbsp;<br class="">&nbsp;<br class=""><span id="cid:image001.png@01D2456F.20C20BC0">&lt;image001.png&gt;</span><br class="">&nbsp;<br class="">&nbsp;<br class="">From:&nbsp;&lt;swift-server-dev-bounces@swift.org&gt; on behalf of Michael Gottesman via swift-server-dev &lt;swift-server-dev@swift.org&gt;<br class="">Reply-To:&nbsp;Michael Gottesman &lt;mgottesman@apple.com&gt;<br class="">Date:&nbsp;Monday, November 21, 2016 at 3:38 PM<br class="">To:&nbsp;Chris Bailey &lt;BAILEYC@uk.ibm.com&gt;<br class="">Cc:&nbsp;"swift-server-dev@swift.org" &lt;swift-server-dev@swift.org&gt;<br class="">Subject:&nbsp;Re: [swift-server-dev] HTTP Parser<br class="">&nbsp;<br class="">&nbsp;<br class=""><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class="" type="cite">On Nov 21, 2016, at 5:55 AM, Chris Bailey via swift-server-dev &lt;swift-server-dev@swift.org&gt; wrote:<br class="">&nbsp;<br class="">&gt;&gt;&nbsp;But it sounds like MIT licensed code can’t be used as part of the effort, maybe that should&nbsp;be added the the front-page of the effort.&nbsp;<br class=""><br class="">I'm not 100% convinced this is true. There's nothing (legally) preventing the inclusion of MIT licensed code in a Apache 2.0&nbsp;licensed product, you just may have to list some Product Unique Terms (PUTs) to cover it - we don't need the Node.js community&nbsp;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&nbsp;guess is that ship has already sailed on using non-Apache 2.0 licensed code.&nbsp;<br class=""><br class="">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.<br class=""></blockquote>&nbsp;<br class="">We want a consistent license over the entire code base. I imagine we will make an external test suite that will be in a&nbsp;different repository so this will not be an issue.<br class="">&nbsp;<br class="">Originally we put the swift perf test suite in the swift tree since people kept on breaking it. Since we use PR testing&nbsp;this is no longer an issue (the benchmarks are built as apart of the PR testing). There are some questions around how&nbsp;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.<br class="">&nbsp;<br class="">Michael<br class=""><br class=""><br class=""><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class="" type="cite"><br class="">Chris&nbsp;<br class=""><br class=""><br class=""><br class="">From: &nbsp; &nbsp; &nbsp; &nbsp;Helge Heß via swift-server-dev &lt;swift-server-dev@swift.org&gt;&nbsp;<br class="">To: &nbsp; &nbsp; &nbsp; &nbsp;"swift-server-dev@swift.org" &lt;swift-server-dev@swift.org&gt;&nbsp;<br class="">Date: &nbsp; &nbsp; &nbsp; &nbsp;20/11/2016 18:08&nbsp;<br class="">Subject: &nbsp; &nbsp; &nbsp; &nbsp;Re: [swift-server-dev] HTTP Parser&nbsp;<br class="">Sent by: &nbsp; &nbsp; &nbsp; &nbsp;swift-server-dev-bounces@swift.org<br class=""><br class=""><br class=""><br class="">Hi Dave,<br class=""><br class="">thanks for your post, this detail is indeed quite helpful.<br class=""><br class="">I don’t think anyone seriously suggested using a Swift port of the http_parser but instead just&nbsp;the upstream C one. But it sounds like MIT licensed code can’t be used as part of the effort,&nbsp;maybe that should be added the the front-page of the effort.<br class=""><br class="">I assume it is not a huge issue though as a libhttp_parser can be shipped separately from Swift&nbsp;itself, similar to what you would do for OpenSSL etc (and what is already being done with&nbsp;libcurl on Linux).<br class=""><br class="">In any case: Whatever is decided, it at least establishes a performance characteristic, I think&nbsp;any replacement should accomplish a comparable one - preferably faster of course :-)<br class=""><br class="">hh<br class=""><br class=""><br class="">&gt; On 20 Nov 2016, at 16:58, David Sperling via swift-server-dev &lt;swift-server-dev@swift.org&gt;&nbsp;wrote:<br class="">&gt;&nbsp;<br class="">&gt; I would like to provide some additional detail to the discussion on November 4 (which I missed&nbsp;since I joined recently).<br class="">&gt;&nbsp;<br class="">&gt; The team pointed out this thread in Kitura which I initially opened:<br class="">&gt;&nbsp;https://github.com/IBM-Swift/Kitura-net/issues/52<br class="">&gt;&nbsp;<br class="">&gt; Here is the referenced Swift http_parser project which I initially ported as a thought&nbsp;experiment. &nbsp;The goals, API and performance are described in the readme.<br class="">&gt;&nbsp;https://github.com/smithmicro/HTTPParser<br class="">&gt;&nbsp;<br class="">&gt; Michael Gottesman from Apple (@gottesmm) contacted me 2 weeks ago to see if we could add the&nbsp;project into the Swift Benchmark Suite. &nbsp;See the bottom of this PR for the request:<br class="">&gt;&nbsp;https://github.com/IBM-Swift/Kitura-net/pull/55<br class="">&gt;&nbsp;<br class="">&gt; Michael and I approached the Node.js Foundation to see if they were willing to dual license&nbsp;http_parser under Apache 2 so it would be compatible with the Swift license. &nbsp;Here is that&nbsp;discussion, but in summary, a dual license is not realistic.<br class="">&gt;&nbsp;https://github.com/nodejs/http-parser/issues/344<br class="">&gt;&nbsp;<br class="">&gt; So, a http_parser Swift port:<br class="">&gt; - Would not have the proper license to be included in Swift<br class="">&gt; - Does not take full advantage of Swift<br class="">&gt; - Has the issues previously pointed out (UnsafePointers, asserts, throws simulating gotos)<br class="">&gt; - Does, however, demonstrate a Swift HTTP parser performance of 500K requests per second<br class="">&gt;&nbsp;<br class="">&gt;&nbsp;<br class="">&gt; Looking forward to meeting everyone on our call tomorrow. &nbsp;Hopefully this detail was helpful.<br class="">&gt;&nbsp;<br class="">&gt;&nbsp;<br class="">&gt; Dave Sperling<br class="">&gt; Smith Micro<br class=""><br class="">_______________________________________________<br class="">swift-server-dev mailing list<br class="">swift-server-dev@swift.org<br class="">https://lists.swift.org/mailman/listinfo/swift-server-dev<br class=""><br class=""><br class=""><br class="">Unless stated otherwise above:<br class="">IBM United Kingdom Limited - Registered in England and Wales with number 741598.&nbsp;<br class="">Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU<br class="">_______________________________________________<br class="">swift-server-dev mailing list<br class="">swift-server-dev@swift.org<br class="">https://lists.swift.org/mailman/listinfo/swift-server-dev<br class=""></blockquote><br class=""><br class="">_______________________________________________<br class="">swift-server-dev mailing list<br class="">swift-server-dev@swift.org<br class="">https://lists.swift.org/mailman/listinfo/swift-server-dev<br class=""></blockquote><br class=""></div></body></html>