Re: [gnet-dev] zero-copy interface?

[Tim Müller <t i m zen co uk>]

On Mon, 2005-11-07 at 21:21 -0500, Jeff Garzik wrote:

Hi Jeff,

> However, a showstopper problem for me is the amount of data copying that 
> occurs in GNet, which really impacts CPU usage in my application.
> 
> I'm interested in modifying GNet as follows, in [my] priority order:
> 
> * figure out how to send integrate sendfile(2) support.  I see its in 
> the TODO.

I'm not convinced that's easily doable or actually useful for all but a
very few applications. As far as I can see, the main problem is the
GIOChannels layer in GLib, and that doesn't really provide for nifty
things like that, does it? You could get the socket fd from GTcpSocket
and handle writes / sendfile() yourself though.


> * figure out some way for app to provide buffer for async write, rather 
> than having GNet memdup it

That looks like it should be fairly easy to do, and it's also a good
thing to have. We could add new API for that, maybe something like:

void
gnet_conn_write_direct (GConn* conn, gchar* buffer, gint length,
                        GDestroyNotify buffer_destroy_func);

That way you could for example pass an mmap()ed buffer and unmap that in
your buffer destroy function when it's been written. Not sure how that
compares to sendfile() performance-wise, but it should make quite a bit
of a difference in any case.


> * figure out some way for app to provide buffer for async read, rather 
> than having GNet allocate and manage it

What's the use case you have in mind for that?  GConn reads into a fixed
per-instance buffer, the only expensive thing involved might be a
g_memmove() when bytes have been processed, but that you can avoid if
you read bytes in any 'denomination' rather than a fixed amount or until
the end of the line.

Cheers
 -Tim