Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62820
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAF+90c-+Hgcv5B4+eGDS+jEj6oNoyefBWO-M=kvThaVdckz62g@mail.gmail.com>
References: <CAF+90c-+Hgcv5B4+eGDS+jEj6oNoyefBWO-M=kvThaVdckz62g@mail.gmail.com>
Date: Tue, 4 Sep 2012 18:00:16 -0400
Message-ID: <CAJzDObe=aKtR46RjKvkeX3_73_Dw=v2KAdOtxLqWFHfut+S8mw@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Moving to an AST-based parsing/compilation process
From: adamjonr@gmail.com (Adam Jon Richardson)

On Tue, Sep 4, 2012 at 3:57 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:
> Hey folks!
>
> Some people asked me what the advantages of using an AST-based
> parsing/compilation process are, so I put together a few quick notes
> in an RFC:
>
> https://wiki.php.net/rfc/ast_based_parsing_compilation_process
>
> It would be nice to get a few comments from other core devs on this.

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.

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.

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