February 1, 2019

January 23, 2019

Please reload

Recent Posts

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....

PHPUnit [Beta] Full-Native Java Test Results

June 11, 2018

1/3
Please reload

Featured Posts

PHPUnit [Beta] Full-Native Java Test Results

June 11, 2018

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.

Share on Facebook
Share on Twitter
Please reload

Follow Us
Please reload

Search By Tags
Please reload

Archive
  • Facebook Basic Square
  • Twitter Basic Square
  • Google+ Basic Square

© 2017 RuntimeConverter