On Fri, 18 May 2001, Andi Gutmans wrote:
>> > of thinking about something which is pretty low-level and it reduces
>> > bloat. I don't really see a downside to this magic.
>>
>>But, the issue here isn't one of which is faster. The issue here is one
>>of memory usage. If you have a 600M iso image that you decide to
>>readfile() for a download page of some sort, then you are going to end up
>>with a 600M httpd process. And soon you will have lots of those as more
>>people hit the page.
>>
>>So to be truely magical here, PHP would have to check the amount of spare
>>RAM on the system, divide that by MaxClients and set that as the largest
>>filesize to mmap() because anything larger could result in the box going
>>into swap.
>>
>>I obviously don't think such a check is feasible. The only real question
>>here is whether to add a user configurable max-mmap setting or to add a
>>second function that never mmaps.
>
>I think we are getting carried away here. Why start bloating with
>configuration options and possible new functions? It's not as if the
>developer needs great control over this.
>I'd either nuke mmap() completely and use regular file functions (it's
>usually not a big loss and I don't think it's a big deal) or take an
>arbitrary number which we think should be considered a large file
>(something like 256KB) and use mmap() only for smaller files.
I'm for nuking the mmap() from readfile().
readfile() is supposed to be used also on remote files and
IIRC mmap() is meant to be used only with regular files.
Do ftell()/fstat() work for remote files?
--Jani
--
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]
