On Fri, 10 Aug 2001, SM wrote:

> At 10:01 10-08-2001 +0200, Daniel Stenberg wrote:
> >In general, I don't mind adding support for different ways to access files.
> >Although I doubt there's much point in optimizing for speed to this degree in
> >disk I/O when we're writing a network utility.
>
> Agreed. What I like about cURL is its portability across several
> platforms. That is more important than an speed improvement in the file I/O.
>

    Right -- and portability can be maintained -- if the necessary
    configure checks are in place. Yes, cURL is a network utility, but
    I don't see why that means that file I/O shouldn't be optimized as
    much as possible?

    Optimally, File I/O should be optimized in two areas -- when cURL
    gets data to write down into a file -- an when cURL reads from
    files for HTTP uploads (the two areas where I believe signifigant
    file I/O is done). There are alot of businesses using libcurl where that
    extra processor cycle *does* matter (at least with PHP there are a few
    that I know of). Yes, premature optimization is the root of all
    evil (or so Knuth says :), but, in this case I think the
    optimizations are worthwhile.

> >mmap() is certainly not as portable as the fopen() of today or even the
> >suggested file descriptor approach. libcurl runs on numerous platforms, and
>
> It will certainly break libcurl on some of the esoteric platforms currenly
> supported. I am wary of any changes to the current file I/O mechanism.
> BTW, I was not suggesting moving to mmap().
>

    Again -- not with a configure check, something like

int Curl_FileRead(curl_file_t *f, const char *file, int length, char **buf)
{
    return
#if defined(HAVE_MMAP) || defined(CURL_WIN32)
    Curl_Mmap_Read(f, file, length, buf);
#else
    Curl_Fd_Read(f, file, length, buf);
#endif
}

    -Sterling

_______________________________________________
Curl-library mailing list
http://curl.haxx.se/libcurl/
Received on 2001-08-11