[swift-server-dev] HTTP Parser
Logan Wright
logan at qutheory.io
Thu Nov 3 15:49:54 CDT 2016
Following up with what Tanner and Chris said. I think HTTP 2 is
particularly difficult, and you're right chris, bringing in a c library,
even if just temporarily will help expedite the process in an efficient way.
I am however pretty ardently against porting C code to Swift as opposed to
rethinking things for a Swift paradigm. If that's the case, I'd prefer to
either link to the c code, or bring it into the Swift compiler. The end
result would appear to be the same.
- Logan
On Thu, Nov 3, 2016 at 4:46 PM Tanner Nelson via swift-server-dev <
swift-server-dev at swift.org> wrote:
>
> Tanner Nelson
> Vapor
> +1 (435) 773-2831 <(435)%20773-2831>
>
> On Nov 3, 2016, at 4:34 PM, Helge Heß via swift-server-dev <
> swift-server-dev at swift.org> wrote:
>
> On 3 Nov 2016, at 19:41, Alfredo Delli Bovi <alfredo.dellibovi at gmail.com>
> wrote:
>
> There has been some discussions about this in Kitura already (
> https://github.com/IBM-Swift/Kitura-net/issues/52) and I think we can use
> what they found out at the moment.
> 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.
>
>
> They claim that their port is just ~1/3 slower, that seems perfectly
> reasonable to me. I’m all for using it.
>
>
> 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.
>
> A big performance hit like that is not worth it unless we're getting
> improved readability or safety out of the code.
>
>
> I also agree with the overall sentiment that a ‘pure’ Swift solution
> should be preferred.
>
> 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.
>
>
> Yes, the API should sit on top of this and be essentially parser agnostic.
>
> hh
>
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev
>
>
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20161103/ef7089d7/attachment.html>
More information about the swift-server-dev
mailing list