Re: Moving to an AST-based parsing/compilation process

From: Date: Thu, 06 Sep 2012 08:25:32 +0000
Subject: Re: Moving to an AST-based parsing/compilation process
References: 1 2 3 4 5  Groups: php.internals 
Request: Send a blank email to internals+get-62850@lists.php.net to get a copy of this message
On 06/09/12 10:11, Stas Malyshev wrote:
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. JIT, lazy-parsing, lazy-opcode generation, caching heuristics, optimisation of opcode generation…
PHP is interpreted and this is why it is able to offer high dynamic constructions and executions. PHP incredibly scales. But we can do better, maybe by mixing cache + interpretation in a better way. I don't know. I said we are certainly not the first ones facing this “problem”. We have to search in the literature if such solutions exist.
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. Not if we expose the AST directly into the PHP user-land (maybe through a specific configuration: --enable-user-ast or something like that).
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. Because it is a very hard topic and so, it is hard to explain quickly.
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. Exactly what I have proposed: “Let's try as a POC and we will quickly see if this is a wrong way or not”.
Cheers. -- Ivan Enderlin Developer of Hoa http://hoa.42/ or http://hoa-project.net/ PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis) http://disc.univ-fcomte.fr/ and http://www.inria.fr/ Member of HTML and WebApps Working Group of W3C http://w3.org/

« previous php.internals (#62850) next »