Phalanger takes advantage of DLR

We are happy to announce that Phalanger 2.1 for .NET 4 (August 2011), our PHP language compiler, takes advantage of Dynamic Language Runtime (DLR) [1] which is present in .NET 4.0 Framework and Mono.

We’ve decided to use DLR for a few PHP operations in order to improve their performance. So far, the operations that use DLR are field read access and instance method invocation. Using DLR improved the performance significantly, for some operations we measured even more than 6x performance improvement. This significant progress was possible because of DLR caching system which is actual implementation of polymorfic inline cache [2].

Before DLR, we were classifying operations into two cases (not counting eval), bound during compilation and bound during run time. The goal for Phalanger as dynamic language compiler is to compile as much as possible as compile-time bound operations and use runtime-bound operations only for cases that can’t be determined during compilation. DLR caching system allows compiling operation at run time when we know particular types for the operation and store compiled operation into cache. This can work efficiently because of the idea that when particular operation occurs, there is a big chance that the next time operands will have the same type.


Following picture shows some selected micro-benchmarks. Each test of an operation was performed ten million times on Core i7 2600, 3.5 GHz, 16GB DDR3 desktop machine, running Windows 7 64 bit with .NET 4.0. You can clearly see the progress we’ve made with Phalanger in this release. The chart shows time required to run the operation 10 million times (so a smaller value is better):

PHP compiler microbenchmark

You may wonder why Phalanger performs static operations so efficiently. The reason is that operation is bound during compilation. At run time there are just few CPU instructions going on. In dynamic operations where we need to bind the operation at run time, we have to do more stuff, but still it’s pretty fast now thanks to DLR.

Our slowest operation at the moment is static method indirect call which is not using DLR. The reason is this operation isn’t frequently used in any PHP application I know. Anyway we are planning to improve it in the future.

If you want to try this benchmark by yourself you can get its sources from the source code repository on CodePlex from \Testing\Benchmarks\Micro directory.

Future work

August release is just the beginning of Phalanger’s incorporation with DLR. We’ve started with re-implementation of just few of the basic operations, mainly because of performance benefit of using DLR caching system. The goal here is that if we can’t bind the operation during compilation, the operation can take performance benefit of DLR. This doesn’t apply to the operations that are already implemented more efficiently in Phalanger and DLR would not improve their execution speed. Such operations are, for example, arithmetic operations, array access, comparison operators etc.


8 thoughts on “Phalanger takes advantage of DLR

  1. Ive been watching thsi project for years, and am really excited by the recent developments. unfortunately too busy at the moment but am looking forward to trying all this out!

  2. I have been following this project for years as well!! Glad to see it’s made it thus far!!! You’re making .NET the best platform (along with all the other DLR implementors)!!! You guys rock and congrats on sucha great release!

    Curious, can Phalanger be used within an mvc project? I will read up on this later if possible!

    • I’m very glad you like our project!

      We’ve never tested Phalanger as a part of MVC project, but I don’t see any reason why it shouldn’t work. It’s just necessary to create MVC project in PhalangerTools for VS2010. Actually one guy used Phalanger as PHP view engine for his own MVC framework – PivoMVC

    • Thanks! Still there are few operations that are little slower, mostly because they are based on .NET dictionaries and regular expressions.
      But we are improving them continuously … luckily overall performance is much better than on PHP.

  3. Curious what are the results like for typical apps when compared against PHP with APC (or some opcode cache) for other operations (string manipulation, array access) ?

    • Basicaly the results will be same whether using opcode cache or not. The main improvment of the caches is caching of parsed php code in form of opcodes so it doesn’t have to be parsed all over again. Therefore, it won’t have any effect on the results of these micro benchmarks since we messure it inside the php code (after parsing). You can try it yourself, just go to to \Testing\Benchmarks\Micro directory and try to run go_php.bat with and without wincache turned on.

      I’ve also put more micro-benchmarks to section , so you can take a look to see other operations.