PHPUnit [Beta] Full-Native Java Test Results
About 2 weeks ago, we published that we had successfully converted a PHPUnit example project and it ran just the same as if it had been run with PHP. The conversion was not "full-native" because while the user-space functions were converted to Java without exception, we did not have implemented in Java all the functions it required from the PHP standard library (we did have most of them, however). The functions not available in Java were passed to PHP in an efficient way, but with some overhead. The result was a script that ran in 24 ms, vs 10ms on PHP.
Now, we have converted the remaining functions used by this script to Java, and re-ran the test. The result is that, after HotSpot optimization test runs, the Java code runs in as low as 8 ms.
Actual Results By Number of Optimization Runs:
0x - 181ms
1x - 23ms
10x - 13 ms
100x - 9 ms
1,000x - 9 ms
10,000 - 8 ms
As noted in the previous post, the first iteration is delayed by the Java class loader and also now by regex compilation.
It would be interesting to see if the time would go to < 1ms if the dynamic function calls were replaced with static calls on static types, but we won't have that feature for a long time and won't be doing any manual work on PHPUnit's converted code.
The implied conclusion here is that the Runtime Converter, when run in full-native mode and with no manual interventions, is neither faster nor slower than PHP. The reason for this is *probably* that the code used by the Runtime Converter uses the same kind of dynamic lookups for method calls as does PHP. So, in doing *exactly* the same thing on *exactly* the same CPU takes *exactly* the same amount of time. In reality there are differences, but this is a good approximation of what one can expect from the Runtime Converter in native-Java only.
Ultimately, this is a very good result because the aim of the Runtime Converter is not to be faster than PHP, but merely to convert PHP to Java. The fact that it can be run at the same speed and not slower means that one major objection can be removed from the conversion process. We also now have verifiable results and real data instead of just guesses as to what will be the effects of using the Runtime Converter to convert a large PHP project to Java.
