On Mon, 13 Feb 2012, Yehezkel Horowitz wrote:

>> if I would reconsider it, someone would have to show a significant
>> performance boost with the use of something like that.
>
> Since such approach will require dynamic buffer allocation, I think this
> could improve the memory foot print as well.
>
> Today even if you want to use curl for small data transfer, it will allocate
> 32K just for upload/download buffers! When using the multi interface with
> lots of such connections this might be significant.

Right, but the current fixed-size 32K (16+16) allocation could easily be
converted into a more dynamic way that either would automatically grow
according to some rule or it could be possible to set with an option.

A first and simple zero-copy implementation for libcurl would still have to
provide the same sized buffer to libcurl since it internally always assume and
work with 16K now.

> I think that 'CURLcode curl_allocate_buffer_cb(char** buff, int* size)'
> which will be called by curl with the requested buffer size - would be easy
> to use API for this.

Yes, I agree it could probably be in that spirit. The actual arguments would
have to be worked on of course.

The actual API to feed pre-allocated buffers into libcurl for this is probably
the easier part of the work! :-)

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html