Andrius, I'm afraid that it may significantly worsen the small-bandwidth connections performance, but it would still be great to see the results!
It seems that, at least on FreeBSD, this syscall is not even acquiring the lock, so the cost should be generally a matter of crossing the boundary between the kernel and the user-space. Cheers, Fedor. On Fri, May 30, 2014 at 9:44 AM, Andrius Bentkus <[email protected]> wrote: > I tried it yesterday. I'm writing an epoll loop implementation in c#, so > that is not js/nodejs or c/libuv. I don't know how the slab allocator works > in node and such but I think the test results would be similar in c/libuv. > > My test scenario was simple, send 5GB of data calling 1MB writes. At the > producing end I was using the blocking API in a separate thread. > > At the receiving end I used epoll with nonblocking reads. Using a static > 64k buffer It took ~8000ms on my machine to send and receive that data. > > The ioctl call added ~20ms overhead. However, the ioctl returned numbers > bigger than 64k. I assumed that 64k was the maximum buffer size for sockets > on linux. So whenever a suggested size of ioctl was higher than my current > buffer size, I expanded my buffer. > The result was that I could send those 5GB of data in ~2050 ms (The > suggested buffer size was around 4 times bigger than 64k, so that kinda > makes sense). Now, I didn't do anything significant with the data, just > receive it, no parsing, no inspection, so the performance gain is purely on > the data shovelling side on fully saturated lines sending a lot of data. > > But the added benefit is that now the allocator callback knows *exactly* > how much memory it needs to provide which means less fragmentation when the > user sends small packets and the callback allocates its memory dynamically. > For just 1% performance decrease and a huge performance gain, since the > maximum size of the buffer can be determined. > > I will write a test case in c/libuv to show these effects. > > -- > You received this message because you are subscribed to the Google Groups > "libuv" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/libuv. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
