Daniel Stenberg wrote:

> On Wed, 30 May 2001, Sterling Hughes wrote:
>
>
>> I was just going through the source and noticed that when reading
>>data with file uploads it uses by default the stdio layer which has quite
>>a nice performance decrement. With larger files this can be
>>signifigant... Best case, I think there should be an option, something
>>like CURLOPT_READOPTIMIZE, which will grab the file through mmap() if
>>available, or if not use the unbuffered i/o layer (open(), read(), etc).
>>
>
>> This might be a bit complex because of the semantics of the
>>CURLOPT_READFUNCTION, and the reading of data in general, however, if
>>there's some way we can figure it out, I'd think it be beneficial in
>>general (especially since file uploads can be quite large.)
>>
>
> Don't get me wrong gere, but why would libcurl have to address this issue at
> all?
>
> I fail to see why the application can't mmap() the file to upload, and then
> just set the proper options to libcurl and then on each read callback return
> a suitable piece of the file? libcurl is only there to supply a decent
> default (which I think it does), if you want specific implementations it
> allows the application to provide them.
>

Good point. I failed to see how that could be done, it makes good sense
  now (I still don't like stdio the inherent speed decrease of using the
stdio layer instead of fd's, but as you said, that can be changed quite
easily).

> I can see that there's gonna be an extra copy operation that could be avoided
> if we offer a different set of arguments to the callback function (which
> indeed can be discussed).
>
> Is that what we should discuss?
>

yep, it would be nice if this could be changed...

-Sterling

-- 
Sterling Hughes
sterling_at_designmultimedia.com
http://www.designmultimedia.com/
_______________________________________________
Curl-library mailing list
Curl-library_at_lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/curl-library