On Tue, Sep 4, 2012 at 3:57 PM, Nikita Popov <nikita....@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
