Re: clarification on the performance of require_once andAPC

On 8/27/07, Gregory Beaver <greg@chiaraquartet.net> wrote: > (...) > 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? This is funny, you probably should have copied the rest of it? I told him to to adjust the include_path and it worked for him. He never complained about it. Even told me that he things he missed out on PEAR before and found it very useful. 00:48 <@till> H1net: quick survey, do you find editing the include_path to be a particulary "hard" thing to do? 00:50 < ***> Generally no - however I've become quite particular about touching config on one of my boxes in the u.s. which has a very old CentOS distro on it and is generally managed by WHM as our customers use Cpanel. The thing is, he just didn't read anything in the first place - that's all. Not like he would have read README or something else telling him to fix the include_path. All in all, still an educational issue. I don't understand where you are coming from trying to please those funky "I don't understand include_path"-demands. I think don't it needs an adjustment, as others have pointed out, it's even common in other languages. For the performance freak, have a phing tool which strips it out and creates "allfiles.php" (I don't like that name at all). Cheers, Till > >> 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. > > 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? > > > 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. > > 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. > > > 3) __autoload() provides some benefits over manual including > > __autoload() provides a way to rapidly develop an application on a > development server, and no performance benefits for the > performance-hungry. In other words, your assertion is false, > __autoload() can provide the benefit of postponing the process of > deciding which files to include() until after you've designed the > application, and then it makes it very easy to decide which ones to > include by putting a var_dump(get_included_files()) in a shutdown > function or by using Gopal's inclued extension. > > > People who can be educated will read the docs, people who can't be > > educated would read neither the docs nor your proposed README files. > > You, being American, may also overlook another issue: while the manual > > can be (and even *is*) translated, most of the stuff installed alongside > > packages will only remain English. > > The official language of comments and code in PEAR is English, that's > why we have translations for the manual. However, this point is > irrelevant to your argument. People who can't be educated can't be > educated, how does the language affect anything? Right now in PEAR, we > have a situation where people can be told in one sentence how to get > started. PEAR2 would be no different, but would also provide > flexibility for other situations that is not possible for PEAR users. > It's just as good as PEAR, only better. > > >> 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? > > >> One obvious example of a process that would be far simpler without the > >> problem of top-level require_once munging is the go-pear script. > >> Currently, it has to do all kinds of non-obvious weird stuff to get > >> things downloaded, and additionally is very difficult to read. If we > >> remove all the require_once, go-pear could literally use the PEAR > >> installer itself by cramming all of the needed files into a single file, > >> and putting the installation script at the top of the file. This would > >> even allow us to consider not using a phar archive for PEAR installation > >> within PHP, but still supporting a single-file installation model. > > > > go-pear script is an edge case. I don't think the solution that makes it > > easier to do some pretty rare task while making it harder to perform > > most other tasks is a good one. > > Fortunately, the proposal in question makes it easier to perform most > common tasks as well as uncommon ones. > > If you think you can provide a better counter-proposal that solves the > problems that have been raised, please do so. > > Greg > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Till Klampaeckel e: mailto:klimpong@gmail.com p: +491704018676 l: http://beta.plazes.com/whereis/till Want to know what's up in Berlin? - http://berlin.metblogs.com