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/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to