Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:40205 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 59101 invoked from network); 2 Sep 2008 07:50:42 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Sep 2008 07:50:42 -0000 Authentication-Results: pb1.pair.com smtp.mail=stas@zend.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=stas@zend.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.163 as permitted sender) X-PHP-List-Original-Sender: stas@zend.com X-Host-Fingerprint: 212.25.124.163 il-gw1.zend.com Windows 2000 SP4, XP SP1 Received: from [212.25.124.163] ([212.25.124.163:12678] helo=il-gw1.zend.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 6A/F3-37657-150FCB84 for ; Tue, 02 Sep 2008 03:50:42 -0400 Received: from us-ex1.zend.com ([192.168.16.5]) by il-gw1.zend.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Sep 2008 10:51:42 +0300 Received: from [192.168.17.37] ([192.168.17.37]) by us-ex1.zend.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Sep 2008 00:51:39 -0700 Message-ID: <48BCF08A.7080108@zend.com> Date: Tue, 02 Sep 2008 00:51:38 -0700 Organization: Zend Technologies User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Gregory Beaver CC: Lukas Kahwe Smith , PHP Internals List References: <0E6B0C09-99C4-4843-A8E6-0B015EB98B4E@pooteeweet.org> <48BAF947.6060708@chiaraquartet.net> In-Reply-To: <48BAF947.6060708@chiaraquartet.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Sep 2008 07:51:39.0267 (UTC) FILETIME=[BB58F530:01C90CD0] Subject: Re: [PHP-DEV] Re: namespace RFC From: stas@zend.com (Stanislav Malyshev) Hi! > The problem is that the loading/unloading of the scanner and parser can > be significant overhead, and by cramming all code into a single file, > can result in a 10%-30% performance improvement over code in separate > files, even with an opcode cache. This has been verified independently Not only this, but the fact that executing 50 different op-arrays, with all setup and teardown that happens on the way, is definitely slower than 1 op-array, and also the fact that early binding on compile stage may be a bit faster when we are dealing with a lot of classes and carefully arrange them. As always, note that the benchmark was loading huge amount of classes and doing nothing but, so don't expect your real-life app to get anywhere near 30% on that. Actually, I have no idea how hard it would be to make big app using a lot of modules and lot of different classes in different modules to work this way, so I'm not even sure it's practical or will give any benefit - since you might be loading a bunch of code you'd never need. But the effect does exist. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com