Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62849
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.203 as permitted sender)
Message-ID: <50485AA6.4090803@sugarcrm.com>
Date: Thu, 06 Sep 2012 01:11:18 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120824 Thunderbird/15.0
MIME-Version: 1.0
To: Leigh <leight@gmail.com>
CC: "ivan.enderlin@hoa-project.net" <ivan.enderlin@hoa-project.net>, 
 "internals@lists.php.net" <internals@lists.php.net>
References: <CAF+90c-+Hgcv5B4+eGDS+jEj6oNoyefBWO-M=kvThaVdckz62g@mail.gmail.com> <504836A3.20904@zend.com>	<50485647.1060102@hoa-project.net> <CAPwsocGPS7JOxn_Lwx4VZziYrse51aMji3JYx_Aj_Y5EVe4v0w@mail.gmail.com>
In-Reply-To: <CAPwsocGPS7JOxn_Lwx4VZziYrse51aMji3JYx_Aj_Y5EVe4v0w@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Moving to an AST-based parsing/compilation process
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

>> The lexing and parsing processes will not be slower than actual, and the
> construction of an AST is a new process. Well, as usual, new process
> requires new resources. But if we look further, it will certainly be a nice
> tool to perform better opcode caching, it will remove a lot of hacks, it
> will allow third-part tools working on safeness, security, quality etc. to
> go deeper at low-costs which is very important for PHP community, it will
> facilitate future works

I don't see how it would lead to better opcode caching. As for
third-party tools, I do not see why third-party tools need PHP to change
the parser. If PHP's parser is not good enough for those tools, they can
have their own parser.

> Maybe the upfront cost of a parse goes up, but once it is parsed and the
> opcodes are cached, you won't have this cost again until you change the
> script. Then you have all of the benefits for every subsequent request.

So far we have not seen not only any of these benefits, but any
explanation of what exactly these benefits would be and any proof they
would actually benefit anybody. I seriously would propose people
interested in this project just take up this project and see if it's
beneficial or not. Just talking about what might happen on the list
would achieve nothing.

> Increased cost once, benefits every time.

For now it looks like quite the reverse - increased performance and
stability costs for everybody, dubious benefits for a small group.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227