Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:40200
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.94.56 as permitted sender)
Date: Mon, 1 Sep 2008 16:28:06 +0200
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <1792371464.20080901162806@marcus-boerger.de>
To: Gregory Beaver <greg@chiaraquartet.net>
CC: Lukas Kahwe Smith <mls@pooteeweet.org>, 
	PHP Internals List <internals@lists.php.net>
In-Reply-To: <48BAF947.6060708@chiaraquartet.net>
References: <0E6B0C09-99C4-4843-A8E6-0B015EB98B4E@pooteeweet.org> <48BAF947.6060708@chiaraquartet.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Re: namespace RFC
From: helly@php.net (Marcus Boerger)

Hello Gregory,

Sunday, August 31, 2008, 10:04:23 PM, you wrote:

> Lukas Kahwe Smith wrote:
>> Hello all,
>> 
>> All the recent discussions about namespaces, have left many of us
>> wondering if our implementation is rock solid or not. However the
>> discussions were not really well organized. This is why I am thankful
>> that Marcus and Felipe have spend the better part of this Sunday to
>> write an RFC [1] that hopefully summarizes all the key concerns. Also
>> they have created a patch that they feel addresses the concerns.
>> 
>> So I ask you all to review the RFC and provide feedback. If you feel
>> something is missing, the best approach is probably to work with Marcus
>> and Felipe directly to get your concerns added. Only if there is a
>> difference of opinion in this process should this be brought to
>> internals. This way we can hopefully keep the discussion more focused on

> Hi,

> This is not a difference of opinion, but I would like to correct a
> misconception:  phar does *not* solve the problem that prompts
> developers to concatenate files.

> 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
> by Zend labs (Stanislav can attest to this) on their machines.  The
> performance difference depends on whether external code is loaded using
> require with absolute path, require_once with relative path, autoload,
> or some mix of these.

> The problem requires streamlining of the loading process for files, and
> could perhaps be addressed by attacking the bottleneck, but is not a
> trivial problem to solve.

> Just wanted to set the record straight.

Please add that info to the rFC.

Best regards,
 Marcus