On Wed, Sep 6, 2017 at 2:46 PM, Zeev Suraski <z...@zend.com> wrote: > I think that actually makes a lot of sense, and not just because of the > supportability – but also because of security. A whole class of security > exploits – buffer/stack overflows, underruns and all sorts of memory > mismanagement become irrelevant when the code is implemented in PHP. I > brought this direction up in a discussion on the Security mailing list a > few weeks ago without any traction – but it probably makes more sense to > discuss it here anyway. > > I think that currently, there are two main challenges: > > 1. Performance – compute intensive logic is way slower in PHP compared > to C. > 2. Delivery method – we don’t currently have a good way of providing > functions that are written in PHP and have them provide the same ‘native’ / > ‘builtin’ experience as functions/classes written in C. > > Regarding #1, often this isn’t very important as not all pieces of code > are that compute intensive. Moreover, if/when JIT materializes, compute > intensive logic in PHP will become a lot faster than it is today and > probably in the same ballpark as C – so it’ll open the door for us > implementing more and more things in PHP. > > Regarding #2 – I think that’s something that can be solved relatively > easily, but admittedly I haven’t completely thought it through (read: I > barely thought about it). > > We could create a mechanism where the contents of certain .php files is > embedded into the binary, compiled during MINIT, and made available pretty > at the same ‘builtinness’ level as C extensions. We’d probably have to be > pretty selective in terms of what goes in there – probably just as > selective as we are with the C-based extensions, but I’d imagine that > things like ext/exif, UUID, and perhaps even things like unserialize() > could find themselves written in pure PHP using such a mechanism. > > Thoughts? > > Zeev >
There has been a discussion about this recently: https://externals.io/message/99366 Nikita
