At 11:10 PM 5/17/2001 -0700, Rasmus Lerdorf wrote:
> > >>Perhaps automatic detection could be option? if (filesize > X)
> > >>blockread else mmap? It seems like the most intuitive way to implement
> > >>it...
> > >>
> > >
> > > Sounds a bit magical. Why not just a block_readfile() function?
> >
> >
> > Mainly the bloat factor, we already have a large core, imho, functions
> > shouldn't be added unless there are no workarounds. Also, it requires a
> > little too much thought, into what sizes are good for mmap() and what
> > sizes are good for block read's (it also requires knowledge of mmap(),
> > because many people might automatically assume that block_read would
> > always be faster). I'm pretty sure if we polled php-general and php-qa
> > (the more "knowledgable" user bases), most people wouldn't really
> > understand what mmap does, or what it is for or when it is beneficial to
> > use it.
> >
> > As for magical, well a bit, but good magic and internal magic (not
> > syntactical magic). I'd assume that most systems have a certain point
> > where mmap is no longer more beneficial than reading a file by chunks.
> > If we can find a reasonable number (or have a user specify that in a
> > configuration option if really necessary), it saves the user the trouble
> > 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.
Andi
--
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]
