> >>>If a system has mmap() a readfile() will mmap the entire file to memory
> >>>and then dump that while without mmap it will read it one block at a time.
> >>>That's a siginificant memory difference and one that may not be expected.
> >>>
> >>>Obviously the mmap will be faster, but if as in bug #10701, someone is
> >>>adding headers or doing something else to really large files, things are
> >>>going to break. Since readfile() already has an opotional argument I
> >>>think the right approach is a separate function that turns the mmap off
> >>>and reads the file block by block. fpassthru() doesn't have an optional
> >>>arg, so we could toggle it there for that function.
> >>>
> >>>Comments?
> >>>
> >>>
> >>
> >>Well, out of the solutions, I think the optional argument to fpassthru()
> >>would be the best. However, why not, as you stated in response to the
> >>bug report, read the file with a custom function and output it,
> >>therefore avoiding the mmap() as well?
> >>
> >
> > Well, the one problem with that is that it can be very inefficient because
> > it stops reading when it hits a newline and you end up always reading
> > partial buffers if the file has newlines in it. Having a function that
> > quickly reads/dumps a file block by block would make this much more
> > efficient.
> >
>
> fread() should handle this, no?
True. But I guess my main issue is still that the behaviour changes
radically based on a hidden configure check (ie. whether mmap is there
or not) and that ensuring a block-by-block read in user space is
inefficient for huge files.
-Rasmus
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
