CODEWITHSUNDEEP
php
Raffael
Raffael

Reputation: 20045

Compilation of PHP- to op-code and having the opcode executed

PHP is usually compiled to opcode by the Zend engine on execution time.

To skip the compiling every time one can use an opcode cache like APC to save the opcode in shared memory and reuse it.

Okay, now it seems that there is no solution yet for just compiling the PHP to opcode and using that. Similar to how you use Java.

But why? I am wondering about that b/c this is a quite obvious idea, so I guess there is a reason for this.

EDIT:

the core question is this:

wouldn't make PHP-compilation make opcode-caching superfluous?

The only "reason" against it would be that you couldn't just fix something on the live-system ... which is anyway bad bad bad practice.

Upvotes: 9

Views: 1415

Answers (1)

symcbean
symcbean

Reputation: 48357

You've given one reason against it.

Another very important one is that if you separate the compile from the runtime both in terms of the time at which each occur but also in terms of the hardware where it runs, you quickly run into complex dependency problems - what happens when you try to run opcode generated by PHP 5.1 on a PHP 5.3 runtime?

It also makes debugging of code harder - since the debugger has to map the opcode back to the source code.

But a very important question you don't seem to have asked let alone answered is what is the benefit of pre-generating the opcode?

Would compiling the opcode prior to runtime have a significant benefit over caching the opcode? The difference would be un-measurably small.

Certainly the raison d'etre for HipHop is that natively compiled PHP code runs faster than PHP with opcode caching at the expense of some functionality. But that's something quite different.

Do you think that having only the opcodes on the server improves the security (by obscurity)?

Upvotes: 3

Related Questions