3 ms·
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
by ciprian_craciun 4y 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").
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.
- avinassh 4y 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_craciun 4y 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.