-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request : update and show all examples for doing zero allocation when using fasthttp. 100% zero alloc for each req / resp. #1764
Comments
It doesn't generate garbage. That's exactly why we have these tests: https://github.com/valyala/fasthttp/blob/master/allocation_test.go What it does do is allocate memory that will be reused over time. And of course it will also generate garbage if you create and destroy structs yourself instead of using the fasthttp Acquire/Release functions. |
@erikdubbelboer ok i get it. thx hope someone can update all the examples to show / have 0 alloc / op instead. |
opening this issue because 0 alloc / op should be used as example instead. i change the title from |
Would it be more accurate to reconsider the representation of "doing nothing" when displaying 0 alloc/op? Could we perhaps offer a benchmark showcasing alloc/op for a basic "hello world" scenario?
I was taken aback by the alloc/op for the "hello world" scenario. Is there a chance I missed something in my approach? Could we illustrate a scenario with significantly reduced alloc/op?
For instance, could we explore employing the HTTP parser for header parsing?
Alternatively, could we examine a scenario where we could utilize the package from uptrace.dev, which boasts zero alloc for parsing HTTP headers, among other features?
P.S.: I'm expressing this as an avid supporter of fasthttp and eagerly anticipating enhancements, as i am adopting this package across various applications.
is there a hello world http parsing example with lesser garbage generated ?
The text was updated successfully, but these errors were encountered: