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 think this is a good point to focus on, there has been a lot of comments about the increased resource cost of the parse. What is being forgotten is that you can offset this against all of the gains you will see as a result. 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. Increased cost once, benefits every time. On Sep 6, 2012 8:53 AM, "Ivan Enderlin @ Hoa" <ivan.ender...@hoa-project.net> wrote: > Hi Dmitry, > > On 06/09/12 07:37, Dmitry Stogov wrote: > >> Hi Nikita, >> >> Personally, I don't see any reason to build AST. As you mentioned >> yourself, it will be slower and will require more memory. On the other hand >> AST itself would allow to perform only very basic optimizations. Most of >> them can be easily done on VM opcode level as well. >> > 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 (implementations, features etc.) for PHP… Moreover, > it may be possible that compiler compilers have a better lexing and parsing > processes than actual? > > Someone said that AST is more “academical”, yes it is and that is why we > can benefit from already done researches in this area to avoid memory > overhead (one among others). We are not the first ones facing this problem. > It requires some researches before starting to develop this. Let's try as a > POC and we will quickly see if this is a wrong way or not. > > Cheers. > > > >> Also, as it's not an easy task, the old "ugly hacks" will be replaced >> with new mistakes, which would require new "hacks" in the future :) >> >> The only real advantage could be an ability to expose AST to PHP scripts, >> but only few people may need it. >> >> Thanks. Dmitry. >> >> On 09/04/2012 11:57 PM, Nikita Popov 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<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. >>> >>> Nikita >>> >>> >> >> > -- > 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/ > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
