eventcore vs boost.asio performance?

[Sönke Ludwig]

Am 05.03.2023 um 16:14 schrieb zoujiaqing:
> On Monday, 20 February 2023 at 08:26:23 UTC, Sönke Ludwig wrote:
>> I'm not sure where it would be today on that list, but I got pretty 
>> competitive results for local tests on Linux a few years back. 
>> However, there are at least two performance related issues still present:
>>
>> - The API uses internal allocation of memory for I/O operations and 
>> per socket descriptor. This is to work around the lack of a way to 
>> disable struct moves (and thus making it unsafe to store any kind of 
>> pointer to stack values). The allocations are pretty well optimized, 
>> but it does lead to some additional memory copies that impede 
>> performance.
>>
>> - On both, Linux and Windows, there are new, faster I/O APIs: io_uring 
>> and RIO. A PR by Tobias Pankrath 
>> (https://github.com/vibe-d/eventcore/pull/175) for io_uring exists, 
>> but it still needs to be finished.
>>
>> Another thing that needs to be tackled is better error propagation. 
>> Right now, there is often just a generic "error" status, without the 
>> possibility to get a more detailed error code or message.
>>
>> By the way, although the vibe.d HTTP implementation naturally adds 
>> some overhead over the raw network I/O, the vibe.d results in that 
>> list, judging by their poor performance on many-core machines, appear 
>> to be affected by GC runs, or possibly some other lock contention, 
>> whereas the basic HTTP request handling should be more or less 
>> GC-free. So those shouldn't be used for comparison.
> 
> First, the io_uring is very much to look forward to! When can you merge 
> this PR?

It doesn't pass the tests and has conflicts, so it needs some work. I 
could look into that, too, but I don't have much time available.

> Secondly, how to optimize memory allocation and release under high 
> concurrency? Nbuff is a great library, and I've used it before.

Apart for accidental allocations in the timer code, there are very few 
allocations in eventcore itself. The allocation scheme exploits the 
small integer nature of Posix handles and keeps a fixed-size slot per 
file descriptor in an array of arrays. Buffer allocations for read/write 
operations are the responsibility of the library user.

In that regard, nbuff should be usable for high-level data buffers just 
fine and although I haven't used it, it sounds like a very interesting 
concept in terms of using range interfaces with network data.

For vibe.d's HTTP server module, I'm using a free list based allocation 
scheme, where each requests gets a pre-allocated buffer that is later 
going to be reused by another request. This means that after a warmup 
phase, there will be few to no allocations per request, at least in the 
core HTTP handling code.