Not native?

I have tested Quercus in the past and in many respects it surpassess "native PHP" both in performance and functionality. It covers a wide variety of PHP functions, is faster than "pure PHP" and because PHP is compiled to Java (instead of emulation) Querqus also gives you access to the vast number of free Java libraries available. Just check the iText PDF library, for instance. Well, the PDF support is in Querqus is actually better than in standard PHP even without that library - being totally free. But - you have the freedom to choose. What are the good free PDF options in standard PHP?

One of the few concerns is to learn the Java way of using database connections but once again, that is an almost trivial task. There may be some other shortcomings but I have yet to see a big show stopper. If an largish application like PhpMyadmin runs without modifications it MUST be very compatible indeed.

Here you can see the status of the querqus PHP suppport:
quercus.caucho.com/quercus-3.1/doc/ ...

You should really try a test install to see how well it performs.

The claim that PHP running as Java byte code surpasses the performance of running PHP running with Zend engine is a fallacy.

Since PHP 4.0 released in 2000 it is not an interpreted language anymore. It compiles the PHP code into Zend opcodes, which are basically equivalent to compiling Java into bytecodes.

There are several extensions that cache compiled PHP into shared memory, so no compilation or disk I/O overhead affects PHP execution.

Since Quercus compiles PHP into Java bytecodes, it is only fair to make performance comparisons by running PHP scripts using an opcode caching extension.

PHP also can run any Java library using the Java bridge that is available since a long time ago. If is there any advantage in using Java libraries, that is something that is not exclusive of when you run PHP with Quercus.

php.net/java

Anyway, the point was not so much about native PHP versus PHP with Quercus, but rather native PHP versus PHP on AppEngine. The matter is that AppEngine imposes restrictions that may or many not make it useless for developing Web applications, regardless of the language.

It would be interesting to learn what are the most important constraints and benefits to help people decide whether it is worth the effort to port or developing PHP applications that can run on AppEngine.

I agree - we need to know which functionality is not available when running under AppEngine. It also raises the question of whether any new security holes have been created by using Quercus.

Of more concern is the incompatibility between Google's Datastore and MySQL. If it is true that the "where" clause in "select" statements can only operate on one column at a time under Datastore[1] then some serious re-writing will be required to support most real-world business applications. Also the failure of Datastore to provide a relational database structure will be a serious drawback to many proper commercial applications - although, personally, I doubt whether many PHP developers would know a REAL (i.e. Codd normalised) relational database if they fell over one!

Geoff

[1] See comment from "Strolling on web" on http://www.webdigi.co.uk/blog/2009/run-php-on-the-google-app-engine/

I admit that this comment may be a sidestep and my opinion is as well that PHP should really be part of the AppEngine.

Anyhow: first: It all depends on what and where one is doing. As a freelancer I always see what the server I am deployng to has to offer. So far 100% of the clients' servers have NO opcode caching. Only my own server has EAccelerator installed. So in practise I enjoy opcode caching very, very seldom. So it is only fair that I compare apples to oranges.

Secondly: opcode caching mainly affects the startup time. After the compilation phase we wee the real differences in language performance. And they are BIG in some cases. I wrote a text analysis/conversion application for a newspaper in 2001 using Java (very, very intensive string handling). A few years back I rewrote it in PHP and the result was appallingly slow. After very, very heavy profiling/optimizing it could finally be run - at 1/40 the speed of Java - which I never optimized. It was practically useless and there was no way of optimizing it any further using standard PHP.

That said, though, I admit there is very little use for any other than standard, clean PHP and as such it would be a welcome addition to the Google environment.

Markku

This article is not really about PHP versus Java, but rather whether you can develop PHP applications to run under AppEngine.

There are obvious gains in using AppEngine, especially in terms of automatic scalability. So the main question is what do you have to give up when you use AppEngine?

As for performance, there are certainly many issues that are not trivial, and so many developers do not grasp how they can achieve better performance.

Using an opcode cache extension is mandatory if you want to avoid being hit by the PHP code to opcode compilation overhead.

Zend intentionally left opcode caching out of the Open Source Zend Engine distribution that comes out with PHP because they wanted to make money from selling their commercial caching extension.

This was requirement from Zend that PHP core developers had to accept or else it would be hard for Zend to survive as a company dedicated to PHP development.

There are many Open Source opcode caching PHP extensions. APC is one of them and it is part of the PECL repository now. Starting PHP 6, APC will be shipped built-in the base PHP distribution.

pecl.php.net/package/APC

These facts should not stop anybody from hosting their applications in a Web server that provides an opcode extension.

If your clients do not run PHP on a hosting service with an opcode extension, maybe they do not have enough traffic to need it. If they need it and the hosting service does not provide a caching extension, there are plenty of other hosting services that provide cheap PHP hosting with caching extensions.


As for CPU intensive scripts performance being slower than in Java, that is just a sign that you may not be using the fastest approach to optimize your scripts.

PHP and Java are managed memory languages. This means that many operations that require more memory, the run-time engine allocates memory for you implicitly.

This contrasts with unmanaged languages like C and C++, on which the developer must explicitly use code that allocates the necessary space for the data structures.

Managed memory languages are more flexible, but this often comes at the expense of dealing with memory allocation and reallocation overhead that you cannot get rid of.

In C or C++, a lot of performance is gained by using local variables, instead of object class variables because local variable take memory from the stack space, which has no allocation overhead. This is the main reason why C/C++ code can run much faster.

So if you want to optimize the performance of PHP code, you should use the PHP built-in functions as much as possible because they were written in C or C++. PHP native functions can run many times faster than Java counterparts.

So now you wonder, why in certain cases Java code can run faster than equivalent PHP solutions? There basically two reasons:

1) You did not use the fastest built-in PHP functions or there are no equivalent built-in functions for the specific CPU intensive tasks you want to perform.

2) The latest Java virtual machines comes with Hotspot. Among other things, Hotspot is a JIT compiler that converts bytecodes into machine native code before executing.

java.sun.com/javase/technologies/ho ...

The equivalent for PHP exists, which is an LLVM JIT compiler extension in PECL, but it is not yet usable.

pecl.php.net/package/llvm

An alternative solution for executing PHP as native machine code is to use the Roadsend PHP compiler.

roadsend.com/home/index.php?pageID= ...

In the past there were no Java to native machine code compilers but there are now. Same goes for PHP. If you want to make fair comparisons, you need to compare each language using equivalent tools.