Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:39950 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 53972 invoked from network); 14 Aug 2008 05:36:40 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 Aug 2008 05:36:40 -0000 Authentication-Results: pb1.pair.com header.from=rasmus@lerdorf.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=rasmus@lerdorf.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lerdorf.com from 204.11.219.139 cause and error) X-PHP-List-Original-Sender: rasmus@lerdorf.com X-Host-Fingerprint: 204.11.219.139 mail.lerdorf.com Received: from [204.11.219.139] ([204.11.219.139:39914] helo=mail.lerdorf.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 39/D7-05165-664C3A84 for ; Thu, 14 Aug 2008 01:36:40 -0400 Received: from [216.145.54.15] (socks3.corp.yahoo.com [216.145.54.15]) (authenticated bits=0) by mail.lerdorf.com (8.14.3/8.14.3/Debian-5) with ESMTP id m7E5aUNv012258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Aug 2008 22:36:33 -0700 Message-ID: <48A3C45D.10400@lerdorf.com> Date: Wed, 13 Aug 2008 22:36:29 -0700 User-Agent: Thunderbird/3.0a2pre (Macintosh; 2008071516) MIME-Version: 1.0 To: Larry Garfield CC: internals@lists.php.net References: <909776579.20080803142659@marcus-boerger.de> <48A36617.5010803@lerdorf.com> <200808140027.53442.larry@garfieldtech.com> In-Reply-To: <200808140027.53442.larry@garfieldtech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (mail.lerdorf.com [204.11.219.139]); Wed, 13 Aug 2008 22:36:34 -0700 (PDT) Subject: Re: [PHP-DEV] Inconsistencies in 5.3 From: rasmus@lerdorf.com (Rasmus Lerdorf) Larry Garfield wrote: > I would also note that "include up front and have a good autoload scheme" > works great if you are writing all classes. If you're trying to use > namespaces and functions, there is no autoload. That makes the autoload > argument moot, and pre-loading everything up front can get ridiculously > expensive in large systems, and even then you don't always know what to load > up front. (Think anything that accepts plugins.) So an answer of "well if > it throws a warning when you do that, don't do that" is simply not realistic > in practice. With an opcode cache, it is actually often more efficient to load everything up front even if you aren't using it all on any given request. By using autoload or other conditional mechanisms you lose the function and class caching mechanism provided by the opcode cache because you have now pushed the creation of these to the executor instead of letting the opcode cache cache them for you. And assuming your include_path setting and your include hierachy is clean so you don't have any or at least only minimal per-include stat overhead, whether you include 1 or 20 files on a request isn't a big deal since they are all going to be in memory anyway. -Rasmus