No they are different beasts altogether. eAccelerator is a bytecode cache (reuses/reprocesses bytecode blocks), whereas Zend Optimizer is kind of like DFI (cars) for PHP. Zend Optimizer does not do the same thing that eAccelerator does - the eAccelerator counterpart would be Zend Accelerator (now called Zend Platform).
The Zend arsenal boasts better benchmarks, but is not inexpensive.
I remember that initially, Zend Optimizer and eAccelerator couldn't even coexist. I think that has been changed, where they simply don't play with each other anymore. As you suggest, only Zend Encoded code runs through Zend Optimizer (ZO). ZO isn't invoked if the code isn't encoded, and so it won't affect unencoded PHP code at all (which is a common myth).
circlical - hosting software development forums * blog
ZO isn't invoked if the code isn't encoded, and so it won't affect unencoded PHP code at all (which is a common myth).
You're wrong there. If the Zend Optimizer is enabled it will be initialised when PHP is initialised and in our benchmarks slows down normal PHP execution. If the file is encoded then it will generally speed up execution since it skips some parts of the PHP interpretation process but our tests showed the ionCube encoder was a better choice for performance.
No they are different beasts altogether. eAccelerator is a bytecode cache
EAccelerator also has an encoder/loader component, and this may be what Andre had in mind when asking whether EA, and its loader component, can read encoded Zend files as well as its own encoded files.
However, the answer is still no.
The compiled code produced by encoding systems such as ours and Zend is not only non-standard, but encoded (hence the term Encoder). EA doesn't add these layers on top not least because there's simply no point as the decoding engine is opensource. So whilst the compiled code from EA is there for all to see, and other parties could support EA encoded files, compiled code is well wrapped up with Zend and ionCube and essentially not accessible without reverse engineering.
A further barrier to a third party trying to process encoded files from other vendors is that the compiled code is non-standard. In the case of ZO, the preoptimised code makes use of new opcodes that do not exist in the public specification of the Zend engine, and a third party would have to understand what those new opcodes did in order to implement them. In the case of ionCube, the compiled code from the encoded files even after the decoding stages is entirely obfuscated, meaning that all the opcodes and associated meta data are "wrong" and bear no resemblance to what they should be. The execution engine in the ionCube Loader is designed to directly process the obfuscated compiled code rather than standard compiled code, and a third party would have to understand how the compiled code had been obfuscated before any headway could be made.
So there are many reasons why a component such as EA cannot process encoded files from other vendors.