Re: clarification on the performance of require_once and APC

Hi, Gregory Beaver wrote:

I just tracked down Rasmus on IRC and asked him lots of questions about require_once and APC performance. I think that all of the questions raised in June with reference to require_once were addressed. Here are the facts: * The problem that was brought to light by HTML_QuickForm with APC was that some files were being included both conditionally and unconditionally. The way APC solved this was simply to not cache the files or classes within them, obviously resulting in slower performance. An example of this is when an HTML element extends another element that is used. The user require_once's a driver, and the other driver conditionally includes it.

Don't quite understand here, can you elaborate?

* autoload is slower than direct unconditional include because it is processed at runtime in the exact way a conditional include is processed * There is no way to improve the performance of require_once other than to remove it and use require With these facts in place, it proves that although the performance difference is small for most users, using require_once has an unavoidable performance hit, and the more calls to require_once, the worse the hit, even with APC in its most optimized state. So yes, performance of *_once *is* an issue, contrary to earlier assertions based on Gopal's blog entries.

Even if there *is* a performance issue, we should weigh both the (small?) performance improvement and the huge inconvenience for people having to do pear -> pear2 move.

The best performance is to be achieved by having a single include statement for each needed file in the entire application.

Better yet performance can be achieved by putting everything into a single file. We should also consider stripping comments and whitespace from this file so that parser's job is easier if the user does not use a bytecode cache.

For users who simply wish to try out a package, performance is not an issue, they just need to have an easy way to include all needed files. This should be done on the application level by including allfiles.php, or by setting up an __autoload().

And here I'd like to re-ask one of my questions. Currently people can run usage examples and tests right after they install the package. After the proposed changes are implemented will they have to mangle usage examples to make them run?

Unlike PEAR, PEAR2 should support both models equally well. With PEAR, the best performance is physically impossible, and beginners often need to require_once several files just to get started.

The "best performance" is not yet achieved, we should put everything into a single file, see above.

There were several synthetic benchmarks posted over the summer that support the relative performance of slow => fast with autoload => allfiles.php => custom allfiles.php, there's no need to rehash that argument. It is also true that the relative "performance" of ease of getting started is include '/path/to/PEAR2/Package/Name/allfiles.php'; => set up include_path/__autoload() => custom allfiles.php. In addition, creating a customized allfiles.php is relatively easy if autoload is possible. Simply use __autoload() and set up a shutdown function that var_dumps() get_included_files().

See above, being unable to run usage examples without mangling them sounds like a major degradation in ease of use.

In short, after extensive research, I still support the initial proposal of removing require_once and adding allfiles.php and a README for each package. In my opinion, the next step is to figure out the best way to make this new system robust in the case of a missing file/class and to document how it should be used. I would like each package to have a top-level README.PackageName file, so that when it is installed or when it is unzipped, this file is easy to find. For instance: pyrus install PEAR2_PackageName PEAR2_PackageName installed into /full/path/to/pear2/ - read README.PEAR2_PackageName to get started

If your target audience is the people who are unable to set up include_path then we have strong empirical evidence that they aren't reading the docs that are available now in a *single* place on PEAR's website. Do you honestly expect them to read those README files scattered throughout the file system?

the README would contain instructions on using allfiles, or on using __autoload(). This file could be autogenerated at packaging time for packages that don't have a customized one, as it would be the same for most packages. Within each file, dependencies, both internal and external, need to be clearly documented at the top of the file. Whether this should be done with only /** */ or additionally with class_exists() and exceptions or some other code-based solution is a decision that needs to be made. I would prefer beginning users to see a clear and simple error message if they try to directly include a file without a missing dependency. Making this possible in a way that does not adversely affect performance is important.

Making users manage dependencies manually rather than automatically including them when needed doesn't sound like an improvement in "ease of use" department, either.