Hyper: Memory pooling

Created on 9 Oct 2016  Â·  7Comments  Â·  Source: hyperium/hyper

This is a feature request for the use of memory pooling in Hyper, to reduce allocations despite the use of asynchronous IO.

See this blog post for more details.

Most helpful comment

Well this https://github.com/valyala/fasthttp for go surpassed the go's standard http library almost 10x by using pools and buffers a lot. Maybe this would improve hyper's response times under heavy loads only. Pooling requests, requests, responses, buffers, streams ...etc

All 7 comments

Did you have specific concerns for hyper?

On Sat, Oct 8, 2016, 10:51 PM Demi Marie Obenour [email protected]
wrote:

This is a feature request for the use of memory pooling in Hyper, to
reduce allocations despite the use of asynchronous IO.

See this blog post
http://www.rubyraptor.org/how-we-made-raptor-up-to-4x-faster-than-unicorn-and-up-to-2x-faster-than-puma-torquebox/
for more details.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/hyperium/hyper/issues/927, or mute the thread
https://github.com/notifications/unsubscribe-auth/AADJFy91Kt-7waNThCyJWWDBVzIdapMBks5qyIDigaJpZM4KR6kx
.

@seanmonstar Basically performance. I would like to see Hyper be as fast at HTTP as any server/client written in C or C++.

@seanmonstar I am thinking of the various String and Vec allocations for data structures such as HTTP headers, as well as the parser objects themselves. The String and Vec allocations can probably be handled better by arena allocation, however.

I do think it'd be interesting to be able to use a pool for it all, and
reduce the number of owned allocations. I also think it will be tedious
work to fully accomplish, and profiles don't show that allocation is a
concern at the moment.

On Sun, Oct 9, 2016, 12:36 PM Demi Marie Obenour [email protected]
wrote:

@seanmonstar https://github.com/seanmonstar I am thinking of the
various String and Vec allocations for data structures such as HTTP
headers, as well as the parser objects themselves.

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
https://github.com/hyperium/hyper/issues/927#issuecomment-252507373, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AADJF4v_0L7LsgAA2eUR8ZlCYyNT52GMks5qyUJRgaJpZM4KR6kx
.

@seanmonstar What is the bottleneck currently?

Well this https://github.com/valyala/fasthttp for go surpassed the go's standard http library almost 10x by using pools and buffers a lot. Maybe this would improve hyper's response times under heavy loads only. Pooling requests, requests, responses, buffers, streams ...etc

Rust doesn't have a GC that it needs to do dances around, like Java or Go, so there's less concern with creating objects on the stack. Strings make use of Bytes, which allow refcounted slices instead of copying and allocating. And there's also now a super basic "cached HeaderMap" for a connection, reusing a possible allocation.

So, I'm going to close this general issue down as fixed. If there are specific pieces that could still benefit, we can open specific issues for those things. :D

Was this page helpful?
0 / 5 - 0 ratings

Related issues

FGRibreau picture FGRibreau  Â·  4Comments

zonyitoo picture zonyitoo  Â·  4Comments

gabisurita picture gabisurita  Â·  4Comments

reem picture reem  Â·  3Comments

mcseemk picture mcseemk  Â·  3Comments