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