Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62821
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 64.22.89.134 as permitted sender)
Message-ID: <50467A92.5000401@ajf.me>
Date: Tue, 04 Sep 2012 23:02:58 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Adam Jon Richardson <adamjonr@gmail.com>
CC: PHP internals <internals@lists.php.net>
References: <CAF+90c-+Hgcv5B4+eGDS+jEj6oNoyefBWO-M=kvThaVdckz62g@mail.gmail.com> <CAJzDObe=aKtR46RjKvkeX3_73_Dw=v2KAdOtxLqWFHfut+S8mw@mail.gmail.com>
In-Reply-To: <CAJzDObe=aKtR46RjKvkeX3_73_Dw=v2KAdOtxLqWFHfut+S8mw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Moving to an AST-based parsing/compilation process
From: ajf@ajf.me (Andrew Faulds)

On 04/09/12 23:00, Adam Jon Richardson wrote:
> I''m not a core developer, but I do have some concerns about this type
> of approach:
>
> As noted in the RFC, most languages do use an Abstract Syntax Tree
> (AST), however, as is also noted in the  RFC, PHP opcodes are
> regenerated by request, which makes PHP very unique amongst languages,
> so there is perhaps a reason to be different here.
Python also generates opcodes if you were to run it on CGI on request. 
However, like PHP will be able to when APC becomes default and ready 
enough, it caches them.
>
> The disadvantages of the AST approach are noted as the potential for
> increased resource requirements. When viewed in the RFC, the brevity
> of the section and the visual weight of its contents perhaps
> understates just how much of a big deal this could be.
>
> PHP as a web technology is run on a myriad of servers and processes a
> huge amount of requests every second across the world. Adding even a
> couple cycles to every request is a very big deal in the scheme of
> things, especially when we live in an age where many other industries
> are making great efforts to reduce resources required for
> goods/services.
APC will make things faster, though, you're missing that. And 
optimisations, which an AST would help, would make it even faster.
>
> There was some mention of caching to alleviate the potential issues,
> and this could bring the cost down, perhaps even saving cycles in the
> long run. Or, perhaps some brilliant work on the processing could
> yield significant resource savings compared to the single-pass
> approach.
>
> My point is that I'm all for improving the PHP internals so as to
> facilitate future work on the core. However, these considerations must
> be carefully weighed against the resource footprint PHP now has, and
> the hope of continuing to make reasonable strides to reduce that
> footprint. Asking a few core developers to use more resources to
> handle hacks, quirks, and decoupling technical issues CAN be the
> preferred alternative if there are real savings in server resources
> used worldwide.
>
> That's not to say this area of work should be avoided. Rather, I am
> saying that I hope any work in this area would give the potential for
> additional resource usage very serious consideration.
>
> Adam
>


-- 
Andrew Faulds
http://ajf.me/