Re: Why change require_once? A brief explanation of motives

On 7/16/07, Greg Beaver <greg@chiaraquartet.net> wrote:

I've been barely following the tremendously long thread on the proposed coding standard changes. Needless to say, I wish that people would approach these from a perspective of assuming goodwill from the PEAR Group and the PEAR president, but I do understand that this is a difficult assumption to make, as one should be suspicious of anyone in power for good reasons.

Greg, the point is that these were tossed out there with very little or no empirical evidence indicating (a) the problem, and (b) that the solution solves the problem. Your post here is one of the first that attempts to do so. Any reasonable person is going to argue when there is insufficient evidence to back a major change such as this. <snip>

Here is a short list of things that are REALLY important to understand: <snip>

2) The suggested changes to usage of require_once in PEAR packages are a radical new idea and do require rational and careful evalution. I must say I am extremely dissapointed with the response so far. I have to encourage every person who has posted FUD without any investigation to in the future please try to back up any posted information with facts, or at the very least links to messages from the archives. Most installer-related conversation is on the pear-core@lists.php.net mailing list, and I have been discussing these changes there for over a year now. As benchmarks have shown, and both Gopal and Rasmus have blogged about, require_once is a major problem for APC and other optimization systems because it forces several stat calls. require_once with relative path makes this even more difficult. On FreeBSD, for instance, stat is a very expensive system call, and can result in being a more significant bottleneck for PHP applications than database access. Gopal has blogged extensively about APC and require_once at http://t3.dotgnu.info/blog/php/.

Greg, FUD goes both ways. Several people have posted benchmarks in the past week, and these almost entirely conflict with each other. Frankly, I'm seeing no evidence showing that using require_once is such a huge performance overhead that it needs to be abolished. Additionally, several of us have remarked that changes were introduced in the PHP 5.2 branch that should have corrected most performance issues with require_once definitively (realpath cache), as well as the fact that recent versions of APC (>= 3.0.14) also have solved this issue. Additionally, please consider that loading library files is a *fraction* of the amount of time spent executing an application in most instances (HTML_QuickForm may be an exception to this). In most applications I've benchmarked, the bulk of the time is spent with database calls and web service calls -- not loading the class libraries. The "15% improvement" gained from require_once is a straw man -- it's a 15% improvement in a fraction of the overall application runtime. Any time such remarks are made, however, they're either ignored or dismissed by proponents of the RFC, instead of addressed and considered. Do you have any relevant, reproducible, and *recent* benchmarks using recent PHP 5.2 and APC releases? And do these show an improvement of anything more than milliseconds? Also, can you post some links to the releant pear-core discussions please, so that the rest of us can read up on the discussions that led to the RFC? <snip>

In addition, the use of require_once automatically limits PEAR packages to use on disk. phar archives are required to modify the source in order to use the package, resulting in a significant possibility of accidental error introduction when post-processing the source.

While I appreciate that ext/phar is now available, my understanding is that the Pyrus installer is still going to be using package.xml and the current package format, not phar. With this in mind, why is this edge case being used as a justification for removing require_once? A build tool can strip out most places where require_once occurs, and can likely be written with enough intelligence to replace conditional requires (such as occur in factories) with class_exists() calls. Why make a rule for something most developers are not using and may never use?

Finally, setting up include_path has proven again and again to be a major issue,

I used to follow pear-general regularly, and rarely if ever saw such an issue arise. In fact, I just searched on the pear-general list for 'include_path' and only came up with a single result that indicated an issue with the include_path. I need to look at the autoload implementation you propose, but my experience of autoloading suggests that it's rare for it to solve any include_path issues. I could see that it might trade include_path for a dirname(__FILE__) stat and include relative from that location, but, frankly, this could be done with or without the include_path, and with spl_autoload available, who knows how many other routines have been registered that could be pulling from other locations? I foresee any include_path issues being traded for autoload issues.

and not just for beginners, as has been asserted in many (rather condescending) emails written in response. I don't think many would consider me to be a beginner, but I regularly run into include_path issues with my development on the PEAR installer. Many times, the installer finds itself accidentally including an older version of PEAR simply because the include_path is set up incorrectly.

Greg, this is again an edge case. Most developers simply set it up once and are fine; they're not mucking about with many different PEAR installs. Additionally, since PEAR is included with a vanilla PHP install, most times they don't *ever* have to update their include_path to get PEAR working.

The same issue has affected my usage of Chiara_PEAR_Server and many many other scenarios. include_path is not a bad thing, I happen to love it, but that doesn't mean I always want to rely upon it. Sometimes, when setting up a "do-this-today" application, I'd rather prototype something that "just works" and then later properly set up an include_path environment, something that is physically impossible with the current PEAR library design.

I think this is a reasonable goal. I'm not convinced that removing require_once is the solution, however. Frankly, I'm seeing an RFC that does the following: * Trades one known and widely used language construct, require_once, for another, autoloading; * with the purpose of saving 15% of a fraction of the execution overhead; * and solving an edge case of installation (phar); * and making tracking down *where* and *when* a class file is loaded much more difficult. Basically, I think that while the goals of the RFC are well-stated, the *whys* behind them have not been (or have not been backed up with sufficient evidence), and that they have neglected to consider other elements of the equation. All that said, I'm not totally against this any more. Like Paddy, I'm coming around. I just think that there's more discussion needed, and more honesty and transparency from all parties. -- Matthew Weier O'Phinney mweierophinney@gmail.com http://weierophinney.net/matthew/