And then I find the magical 'if(!issock) {' line.. :)
But still I'd rather nuke mmap..HOW fast is it anyway
compared to reading/writing in chunks?


On Fri, 18 May 2001, Jani Taskinen wrote:

>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?

PHP Development Mailing List <>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to