<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" 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 4:34 PM, Helge Heß 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 class="">On 3 Nov 2016, at 19:41, Alfredo Delli Bovi <<a href="mailto:alfredo.dellibovi@gmail.com" class="">alfredo.dellibovi@gmail.com</a>> wrote:<br class=""><blockquote type="cite" class="">There has been some discussions about this in Kitura already (<a href="https://github.com/IBM-Swift/Kitura-net/issues/52" class="">https://github.com/IBM-Swift/Kitura-net/issues/52</a>) and I think we can use what they found out at the moment.<br class="">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.<br class=""></blockquote><br class="">They claim that their port is just ~1/3 slower, that seems perfectly reasonable to me. I’m all for using it.<br class=""></div></div></blockquote><div><br class=""></div>As far as I can tell, the package in question here is a carbon copy of the C parser (UnsafePointers, asserts, global funcs). The only difference is it's 1/3 slower. </div><div><br class=""></div><div>A big performance hit like that is not worth it unless we're getting improved readability or safety out of the code. </div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">I also agree with the overall sentiment that a ‘pure’ Swift solution should be preferred.<br class=""><br class=""><blockquote type="cite" class="">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.<br class=""></blockquote><br class="">Yes, the API should sit on top of this and be essentially parser agnostic.<br class=""><br class="">hh<br class=""><br class="">_______________________________________________<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="">https://lists.swift.org/mailman/listinfo/swift-server-dev<br class=""></div></div></blockquote></div><br class=""></body></html>