Re: clarification on the performance of require_once andAPC

Hi, Gregory Beaver wrote:

So these are deficiencies in a third party product that we want to work around. OK, what are the *other* third party products that we will treat the same way?

This doesn't make sense to me, could you rephrase the question?

There are problems when APC is used with PEAR. There are no problems when APC is not used. Therefore we should fix PEAR. I'd like to see the full list of third-party applications problems in which would prompt us to fix PEAR.

Of course the file shouldn't contain any require_once calls as it will just contain all the code. Let's enforce the "one package --- one file" rule: it will both improve performance and ease of use, since even the most clueless user won't have any problems understanding which file to include.

I realize you're trying to be funny here, but your suggestion is not flexible. "one package --- one file" is inflexible in that you must always include all of the files at once, which is in fact less efficient than including just the part you need.

I'm not trying to be funny, I'm trying to point out that it's *you* who are making the "best performance" argument, so *you* should be willing to make yet another step in this direction. I honestly don't see the difference between require 'MDB2/allfiles.php'; and require 'MDB2.php'; where MDB2.php is the file containing all the code of MDB2 package, other than the latter being faster and easier for the newbie who doesn't have to remember the 'allfiles' part.

If a package has lots of drivers, which most PEAR packages do, it requires both a lot more memory and more processing time to load the single file. Your counter-proposal provides ease to only one audience, those who want a single-file solution for absolutely everything, and does not help those looking for ultimate performance.

How exactly is my proposal different from allfiles.php proposal? I'm not advocating putting a package and all drivers, the user will do: require 'MDB2.php'; require 'MDB2/mysql.php'; as needed. But this will be faster than require 'MDB2/allfiles.php'; require 'MDB2/mysql/allfiles.php'; and easier to remember and type also.

This of course nullifies the "PEAR2 should be easily relocatable" claim made here: http://wiki.pear.php.net/index.php/Pear2_require

No, it does not, Alexey. Examples are never used on a production server, and the only code that needs to be easily relocated is the php_dir, data_dir and www_dir code.

OK, fair enough.

Remember also that application developers may want to use PEAR libraries bundled in their applications. All of the steps that make it easier for application developers to distribute their applications with PEAR also make it easier to bundle PEAR libraries inside applications that are NOT installed via the PEAR installer - which is as you point out, the most common use case. It would also make it very easy to upgrade a package that is bundled, a major problem we have with PhpDocumentor (HTML_TreeMenu version -1.3.4 is used currently, and is about 300 years out of date, but upgrading is too painful because of the CVS work).

The only thing that's needed to make PEAR libraries more easy to bundle is to update the way they locate data files and such. Other than that, bundling the library right now is a small matter of updating the include_path (and no, I'm not buying the argument that it's too difficult for a person who is already distributing some app).

Did it also not occur to you that by making PEAR friendlier to applications that there may be a few more created that are installable by PEAR?

I don't see how this proposal makes it any easier for app authors.

I am also a consumer of libraries, and use them in a number of projects that don't involve PEAR at all. My experience with setting up the PEAR environment just to use a single PEAR library has been extremely frustrating in every case. Having the flexibility to download a single library, simply extract it and start to use it would be great.

We both understand that you *can* do that now, even with no problems if the library does not rely on data files. Of course you need to jump through some hoops if it does use these files, but you just suggest to replace these hoops by some other ones...

Even better would be if when the application becomes more complex, I could convert this extracted installation into a PEAR installation to update the library.

OK, I installed this app on my Linux box via tar xzf ./configure make make install Please outline the process by which I will make this app known and upgradeable via rpm and / or apt.

As I remember it, include_path is an innovation that was introduced into PHP in order to support PEAR. Most users use direct inclusion or assume that they are simply including files relative to the current directory, without knowing that include_path often contains "."

This "innovation" is available in most other programming languages. So people who are familiar with programming in general, should understand what "library path" is about.

Then why is it that every day someone comes on to #pear and asks a question that demonstrates they have never heard of it?

Because they have no experience in programming? My opinion is that educating these people would do them more good than trying to shield them from harsh reality. ;]

From today (nickname blanked):

[17:35] <***> I'm a little confused, if I use the cli to install a pear package do I still need to download the package to my web_root? [17:45] <***> should including a pear file such as include("DB.php") grab from my pear directory magically?

Your contention that this proposal is designed to attract stupid people is a straw man argument - no one benefits from attracting stupid people. However, there are plenty of smart PHP developers who are simply not as familiar with include_path because they've never needed to know about it.

My opinion is that solution to include_path problems is not getting rid of include_path, but educating people about include_path. Here is also my rant on how stupid package design decisions contribute to these problems: http://marc.info/?l=pear-dev&m=118474842223805&w=2

First of all, the proposal is not to get rid of include_path, but instead to make it encouraged but unnecessary to get started. The problem in MDB you point out would have been solved by a better loader design, one that used a forced error (exception) rather than PEAR_Error, and an error message that said exactly which package was missing. BOTH solutions are part of the proposal for PEAR2, and so make your rant irrelevant unless the PEAR2 proposal is not accepted.

...and both solutions can be implemented without any jump to PEAR2.

Now, to rebut the crux of your previous message:

There are essentially 3 issues that need debunking in the proposal 1) We can get really huge speed improvements with APC

??? Have you read the benchmarks? You linked from a blog entry of Gopal's that talked about one minor change that resulted in a doubling of pages served per second. If we couldn't get huge speed improvements from using APC, who would use it?

Sorry, this should really mean "we can get really huge speed improvements with APC if we go require_once -> PEAR2 proposal".

2) include_path is hard (and we can cleanly get rid of it)

This is a bogus argument, no one is trying to get rid of include_path, and I have already clearly demonstrated that include_path *IS* hard to understand and to use, you simply ignore it by saying anyone who doesn't is not a programmer.

No, I say that include_path is a very common and flexible instrument, and if a person is unfamiliar with it then he must be educated in its use. PEAR makes use of pretty advanced concepts, and if the person is able to grasp classes / exceptions / whatever else then we can expect him to understand include_path also. Though we must make it easier for him, not repeating the errors I outlined above.

All we are trying to do is make it possible (not recommended - possible) to use PEAR packages as unzip-and-go. Yes, this is a real possibility - PhpDocumentor functions almost as well as an unzip-and-go package as it does installed by PEAR. In fact, it is better when installed by PEAR, as less configuration is needed, but it still works as unzip-and-go if you modify the path inside one file. I have years of experience coding an application to work under both systems, and even more coding the installer and dealing with user's problems grappling with PEAR and include_path. Believe me, it is possible to code applications now using PEAR that work in both settings, but it is inordinately difficult, and these changes would make that far easier.

phpDocumentor is an app, not a library. I use it a lot, but never included any phpDocumentor classes in my apps. It also bundles all its dependencies, including non-PEAR ones. This is vastly different from what a library should do.

All that the new proposal mandates is that we stop using top-level require_once. The rest is experimental solutions to doing things, and all possibilities should be explored until we find one that makes coding with PEAR2 packages just as easy as coding with PEAR packages.

OK, the $100 question: if such a possibility is not found, will you consider dropping the proposal?

Of course. When such a possibility is found, will you be willing to recognize it?

Of course. But right now the whole thing looks to me as a clever solution to a problem that does not exist.