undefined | Better HN

0 pointsciprian_craciun3y ago0 comments

The main problem with Go when it comes to raw performance is heap memory allocation. `fasthttp` (and the rest of Kawipiko's code on the main serving path) does all it can to avoid any sort of memory allocation (or "heap escape").

On the other hand, Go's `net/http` uses quite a bit of heap allocation, thus it will never beat `fasthttp` in terms of raw performance.

That being said, the numbers are pointless... From what I remember Go's `net/http` is able to serve a few tens of thousands of requests per second, thus it won't be the main bottleneck.

0 comments

avinassh3y ago

> The main problem with Go when it comes to raw performance is heap memory allocation. `fasthttp` (and the rest of Kawipiko's code on the main serving path) does all it can to avoid any sort of memory allocation (or "heap escape").

How do they manage to do that? One aspect I can think of is, trying not to use pointers and data structures with dynamic size

ciprian_craciunOP3y ago

> How do they manage to do that? One aspect I can think of is, trying not to use pointers and data structures with dynamic size.

On the contrary, they do use lot's of pointers (actually byte slices) and structures with dynamic size, however they rely heavily on buffer pooling and carefully appending to such byte buffers instead of allocating new ones.

j / k navigate · click thread line to collapse