|
On Monday 29 November 2010, Per Jessen <per@xxxxxxxxxxxx> wrote: > Daniel Molina Wegener wrote: > > On Sunday 28 November 2010, > > > > Larry Garfield <larry@xxxxxxxxxxxxxxxx> wrote: > >> There are many things that everybody "knows" about optimizing PHP > >> code. One of them is that one of the most expensive parts of the > >> process is loading code off of disk and compiling it, which is why > >> opcode caches > >> are such a bit performance boost. The corollary to that, of course, > >> is that more files = more IO and therefore more of a performance hit. > >> > > It depends on the implementation that PHP uses to open the file. For > > > > example on Linux and similar operating systems, PHP uses the mmap(2) > > function instead of read(2) or fread(2) functions, so it maps the > > complete file into memory, that is more faster than using partial file > > reads. > > I doubt if a read(file,1Mb) and an mmap(file,1Mb) will be very > different. The file has got to be hauled in from disk regardless of > which function you choose. Well, they are different. That's why some php functions and a wide variety of language implementations are using mmap(2) instead of read(2) to read files from the hard drive for inclusion or module importing. Also Apache uses sendfile(2) and mmap(2) when they are available on the platform because are more faster than read(2). You just can trace how php loads certain modules when you call include(), require(), include_once() and require_once(). Also Python, Perl and other languages have a similar implementation when they are loading modules. read(2) depends on the VFS blocksize, which is used as the maximum unit for chunk reads, mmap(2) not. Just check the PHP source code or run an strace(1) over php loading modules and check which function is used to read inclusions. Best regards, -- Daniel Molina Wegener <dmw [at] coder [dot] cl> System Programmer & Web Developer Phone: +56 (2) 979-0277 | Blog: http://coder.cl/ |
Attachment:
signature.asc
Description: This is a digitally signed message part.
