Do some profiling

[dom96]

It might come as a surprise to some but I haven't actually profiled httpbeast thus far. I am getting more curious whether there are some low hanging fruit there to optimise.

I'll probably do it eventually, but if someone is interested in having a crack at it, please share what you find :)

[kubo39]

I've found httpbeast calls fcntl(2) every time to set nonblocking, even if it uses accept4(2).

[ajusa]

I did some profiling, leaving some notes here: https://github.com/dom96/httpbeast/blob/5202b4c67ad2ed86346e2c35ae168f6f7af30e57/src/httpbeast.nim#L252-L253

These lines are a bit expensive - we could probably forgo the buffer and recv directly into the data.data string

https://github.com/dom96/httpbeast/blob/5202b4c67ad2ed86346e2c35ae168f6f7af30e57/src/httpbeast.nim#L432-L443 The int to string conversions here are a little costly - using something like https://github.com/brentp/mosdepth/blob/master/int2str.nim and appending directly to the buffer would be faster.

[dom96]

Thanks @ajusa!

The int to string conversions here are a little costly - using something like https://github.com/brentp/mosdepth/blob/master/int2str.nim and appending directly to the buffer would be faster.

Regarding this, would it makes sense for Nim proper to adopt it for all int to str conversions? That way we can optimise everyone's code :D

[ajusa]

Potentially, though I seem to recall Araq being against stdlib optimizations since they seem to inevitably break someone's code.

Additionally, I'm suggesting a different proc signature - rather than the proc allocating the string (as $ does), you pass in a var string for it to append onto. I'll look into it further if I have time.

[dom96]

though I seem to recall Araq being against stdlib optimizations since they seem to inevitably break someone's code.

Hm, for what it's worth: I think if that happens we can revert, I don't think we should be this defensive.