Re: allfiles.php has nothing to do with performance -please read the proposal CAREFULLY

Joshua Eichorn wrote: > Gregory Beaver wrote: >> Alexey Borzov wrote: >> >>> Hi, >>> >>> Gregory Beaver wrote: >>> >>>> Several people have mistakenly cited allfiles.php as a >>>> performance-based >>>> decision. It is not. >>> Maybe that's because *you* claim that it is a performance based >>> decision? >>> >>> >>> http://wiki.pear.php.net/index.php/PEAR2_Standards#Loading_all_files_at_once >>> >>> >>> "PEAR2/PackageName/allfiles.php is the "load all classes at once for >>> easy startup and *opcode caches friendliness*" >>> >> It appears this was a confusion on one of the editor's part >> (http://wiki.pear.php.net/index.php?title=PEAR2_Standards&diff=169&oldid=156), >> >> I was not aware the language had been changed. I understand now why >> everyone is saying this! I have edited the standards to remove this >> statement, thanks for pointing it out. >> > allfiles.php is opcode cache friendly, that doesn't mean its the > fastest. Though in many pear packages allfiles.php + apc would be the > fastest because all the files get loaded in normal use. > > But anyway I can see how this could be confusing to people. Yes, but removing require_once also is opcode cache friendly, and the purpose of allfiles has nothing to do with that as if doesn't distinguish allfiles from other solutions. >>>> The purpose of allfiles.php is to provide a >>>> vector to do two things: >>>> >>>> 1) beginners who just want to see how a package works and do not yet >>>> have PEAR installed can simply use this procedure to try a package out >>>> >>> A better solution would be to provide a "one file - one package" >>> distribution or a phar file. >>> >> This makes a great deal of sense to me, and it does solve the problem in >> a better way than allfiles.php. > The biggest problem with the 1 file is that means you have to support a > package in multiple forms which can hurt error reporting wise. Its also > less flexible. > > One file also keeps you from easily building justTheFilesINeed.php Using a phar would of course preserve line numbers. Gopal informed me on IRC that it is his educated guess that APC may actually be faster with phar archives than with files on disk when he writes the new code for APC (probably APC 3.1). Of course (and he was the first to point this out) vaporware is still vaporware until it is written, but the prospect is exciting. However, we do need to seriously consider the potential problems of distributing as both a phar and as a .tgz. Greg