Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:40192
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain chiaraquartet.net from 208.83.222.18 cause and error)
Message-ID: <48BAF947.6060708@chiaraquartet.net>
Date: Sun, 31 Aug 2008 15:04:23 -0500
User-Agent: Thunderbird 2.0.0.16 (X11/20080724)
MIME-Version: 1.0
To: Lukas Kahwe Smith <mls@pooteeweet.org>
CC: PHP Internals List <internals@lists.php.net>
References: <0E6B0C09-99C4-4843-A8E6-0B015EB98B4E@pooteeweet.org>
In-Reply-To: <0E6B0C09-99C4-4843-A8E6-0B015EB98B4E@pooteeweet.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: namespace RFC
From: greg@chiaraquartet.net (Gregory Beaver)

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.

Thanks,
Greg