<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Hi Guys,</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">I think it's also important to look a bit towards the future: the language will evolve. Performance bottlenecks that exist now will surely be over ome by future development. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">As far as the swift implementation's performance at this moment goes, I am actually in the process of rewritting Criollo (incl parser) entirely in Swift. (Objc & CFHTTPMessage now)</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Cătălin <br><br>Sent from my iPhone</div><div><br>On Nov 3, 2016, at 19:51, Tanner Nelson via swift-server-dev <<a href="mailto:swift-server-dev@swift.org">swift-server-dev@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8">I think it's important to remember that performance is not the only concern.<div class=""><br class=""></div><div class="">If we need to use the node_http parser because of time constraints, I'd prefer that over creating a non-Swifty copy. If you want the functionality of UnsafePointers, C is the better language to be working in.</div><div class=""><br class=""></div><div class="">Going forward I think a Swifty HTTP parser could get decent performance. More importantly though it would be incredibly concise, readable, and maintainable.</div><div class=""><br class=""><div class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="font-variant-caps: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><font color="#5f5f5f" class="">Tanner Nelson</font></div><div style="color: rgb(0, 0, 0);" class=""><font color="#9dacd1" class="">Va</font><font color="#aeb2cf" class="">p</font><font color="#c8bacd" class="">o</font><font color="#d0becc" class="">r</font><font color="#9dacd1" class=""> </font></div><div class=""><font color="#676767" class="">+1 (435) 773-2831</font></div></div></div></div></div></div></div>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On Nov 3, 2016, at 2:42 PM, Logan Wright via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="">swift-server-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Completely agree Alex, I also feel strongly about the language in general, and I think if we're going to take the time to build out Swift server apis, they should be in well, Swift.<br class=""><div class=""><br class=""></div><div class="">In terms of performance, Swift will only continue to improve in performance, and given our access to the compiler team and the smart minds in this room. I think we can beat the node parser with time.<br class=""><br class="">- Logan</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Thu, Nov 3, 2016 at 2:41 PM Alfredo Delli Bovi <<a href="mailto:alfredo.dellibovi@gmail.com" class="">alfredo.dellibovi@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg">Hi people,</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">There has been some discussions about this in Kitura already (<a href="https://github.com/IBM-Swift/Kitura-net/issues/52" class="gmail_msg" target="_blank">https://github.com/IBM-Swift/Kitura-net/issues/52</a>) and I think we can use what they found out at the moment.</div><div class="gmail_msg">In my opinion, if we are not able to give the same (or better) performance we should go for a wrapper of a more performant lib, such as http_parser.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Of course it’s also matter of the workload that have, we could always start with a wrapper, so we are able to define the APIs layer and ship a version with it and later on changing the implementation with a pure Swift.</div><br class="gmail_msg"><div class="gmail_msg">
<div style="letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; word-wrap: break-word;" class="gmail_msg"><div class="gmail_msg"><table cellspacing="0" cellpadding="0" style="background-color:rgb(255,255,255);padding:0px;margin:0px;font-family:'Lucida Grande',sans-serif;font-size:12px;color:rgb(176,176,176)" class="gmail_msg"><tbody class="gmail_msg"><tr style="margin:0px;padding:0px" class="gmail_msg"><td style="margin:0px;padding:0px;white-space:nowrap" class="gmail_msg"><span style="font-family:'Helvetica Neue',san-serif;color:rgb(73,79,80);font-size:14px;white-space:normal" class="gmail_msg">—<br class="gmail_msg"></span></td></tr></tbody></table></div></div></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div style="letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; word-wrap: break-word;" class="gmail_msg"><div class="gmail_msg"><table cellspacing="0" cellpadding="0" style="background-color:rgb(255,255,255);padding:0px;margin:0px;font-family:'Lucida Grande',sans-serif;font-size:12px;color:rgb(176,176,176)" class="gmail_msg"><tbody class="gmail_msg"><tr style="margin:0px;padding:0px" class="gmail_msg"><td style="margin:0px;padding:0px;white-space:nowrap" class="gmail_msg"><span style="white-space:normal" class="gmail_msg"><font face="Helvetica" class="gmail_msg">Alfredo Delli Bovi</font></span><span style="font-family:'Helvetica Neue',san-serif;color:rgb(73,79,80);font-size:14px;white-space:normal" class="gmail_msg"> </span></td></tr></tbody></table></div></div></div></div><div style="word-wrap:break-word" class="gmail_msg">
<br class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On 3 Nov 2016, at 19:35, Logan Wright via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>> wrote:</div><br class="gmail_msg m_-1244621901887630693Apple-interchange-newline"><div class="gmail_msg"><div dir="ltr" class="gmail_msg">Helge, definitely depends on the underlying network/dispatch scheme that we go with. I doubt we'd pull in my original code 1:1. But it does speak to my experience w/ the RFC spec in particular.<div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I'd personally opt for pure-swift over c-wrapper. I think it will be easier to maintain/deploy/optimize going forward. I don't have an inherent problem w/ the nodejs parser aside from that if people strongly prefer to use c-code here.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">- Logan</div></div><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Thu, Nov 3, 2016 at 1:27 PM Helge Heß via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Logan,<br class="gmail_msg">
<br class="gmail_msg">
On 03 Nov 2016, at 17:50, Logan Wright <<a href="mailto:logan@qutheory.io" class="gmail_msg" target="_blank">logan@qutheory.io</a>> wrote:<br class="gmail_msg">
> Yup, you can see a lot of it in the underlying engine module from Vapor.<br class="gmail_msg">
<br class="gmail_msg">
is it this one?:<br class="gmail_msg">
<br class="gmail_msg">
<a href="https://github.com/vapor/engine/blob/master/Sources/HTTP/Parser/HTTPParser.swift" rel="noreferrer" class="gmail_msg" target="_blank">https://github.com/vapor/engine/blob/master/Sources/HTTP/Parser/HTTPParser.swift</a><br class="gmail_msg">
<br class="gmail_msg">
that seems to be a pull based / blocking parser, right? That probably doesn’t work for a lot of environments.<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
Personally I’d suggest a small wrapper around this one:<br class="gmail_msg">
<br class="gmail_msg">
<a href="https://github.com/nodejs/http-parser" rel="noreferrer" class="gmail_msg" target="_blank">https://github.com/nodejs/http-parser</a><br class="gmail_msg">
<br class="gmail_msg">
It is small, fast, highly efficient, zero copy, push based, supports chunked&upgrade and is extremely well tested and widely deployed.<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
I also did a straight port of that to Swift, though if you can use the C version I wouldn't use the port as it is significantly slower (and may have extra bugs introduced during the port):<br class="gmail_msg">
<br class="gmail_msg">
<a href="https://github.com/NozeIO/Noze.io/tree/master/Sources/http_parser" rel="noreferrer" class="gmail_msg" target="_blank">https://github.com/NozeIO/Noze.io/tree/master/Sources/http_parser</a><br class="gmail_msg">
<br class="gmail_msg">
My approach here was to keep it close to the original, which makes for really ugly code :-)<br class="gmail_msg">
I think it may be worthwhile to do another attempt of a port of the parser, but less 1:1 like mine, in a Swiftier way (the original uses a lot of goto’s :-).<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
As mentioned, I wouldn’t expect people to use the low level API but rather have nice objects filled by the underlying parser. What about `WORequest` & `WOResponse`? :-)<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
BTW: Something I consider important to discuss across all areas of interest (crypto, sockets, HTTP) is a protocol to represent a chunks of bytes and chunks of chunks of bytes (buckets and brigades in Apache terms). Of course that could be just NSData or DispatchData but I expect that some frameworks have their own way to represent such buffers, hence a protocol would be nice.<br class="gmail_msg">
Why important? Well, because there needs to be a way to pass the data between those components w/o copying it :-)<br class="gmail_msg">
<br class="gmail_msg">
hh<br class="gmail_msg">
<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
swift-server-dev mailing list<br class="gmail_msg">
<a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-server-dev</a><br class="gmail_msg">
</blockquote></div>
_______________________________________________<br class="gmail_msg">swift-server-dev mailing list<br class="gmail_msg"><a href="mailto:swift-server-dev@swift.org" class="gmail_msg" target="_blank">swift-server-dev@swift.org</a><br class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-server-dev</a><br class="gmail_msg"></div></blockquote></div><br class="gmail_msg"></div></blockquote></div>
_______________________________________________<br class="">swift-server-dev mailing list<br class=""><a href="mailto:swift-server-dev@swift.org" class="">swift-server-dev@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev">https://lists.swift.org/mailman/listinfo/swift-server-dev</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-server-dev mailing list</span><br><span><a href="mailto:swift-server-dev@swift.org">swift-server-dev@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev">https://lists.swift.org/mailman/listinfo/swift-server-dev</a></span><br></div></blockquote></body></html>