Lukas Smith got a chance to catch up with Rasmus Lerdorf (and others in #php.pecl) and "talk shop" about topics including handling large libraries and maxclients settings.

In this first post I will provide a link and some commentary on Rasmus's points regarding Doctrine (note I left independent chatter in the log in order to not have any chance of me filtering the content, but there is very little of that so I hope the discussion is still easy enough to follow).

Lukas introduces Doctrine briefly (what it does) along with some general thoughts on ORMs and making code a bit more bye code cache friendly.

Joshua Eichorn points out an interesting project in a new post to his blog today - quercus.

I found an interesting project, quercus that compiles PHP to Java Bytecode allowing it to run ontop of the Java Resin Application Server. It has a couple neat features, one being PHP6 compatible unicode support, the other being easy integration between Java and PHP code.

He gave it a shot and notes that the performance seems decent and allows you to compensate for some of the differences in the PHP API it supports and what you're using via a Java class. According to their site:

Quercus is Caucho Technology's 100% Java implementation of PHP 5 released under the Open Source GPL license. Quercus comes with many PHP modules and extensions like PDF, PDO, MySQL, and JSON. Quercus allows for tight integration of Java services with PHP scripts, so using PHP with JMS or Grails is a quick and painless endeavor.

It includes several extensions too, including the JSON library, APC, MySQL and Oracle support, and PDF functionality. Check out their Getting Started guide, documentation, or their wiki for more information.

In a new post on his blog, Lukas Smith warns developers working with autoload and byte code caches that things may not be as speedy as they might seem.

While it seems kind of nice one must be weary of the idea that they speed up your code. If you are running a byte code cache (which anyone who cares about performance of course does) you will get quite the opposite.

He includes a quote from an IRC log with Rasmus Lerdorf as to the reason why. Mainly, it has to do with the fact that autoload is runtime dependent as opposed to the byte codes which are handled and cached when working with apc.

So, what does this mean for performance? If you really want to squeeze those few extra bits of time out of the execution of your scripts, static includes are the way to go.

Alan Knowles has posted this post about some of the thinks that came from a previous post he did concerning a tool for encrypting PHP scripts. In this new post, however, he mentions something on the other side of the equation - a "PHP recovery tool".

Someone posted a comment on a post I did a while back about a product that was supposed to provide encryption on PHP scripts. (That blog post was probably my most controversial, as the author of the application send me an email asking me to contact his lawyers....)

The post this time was about another magic cure, php recovery, a new web site claiming (or appearing to) sell a product to recover php source code after it has been encrypted. Well, considering my last post, using plain old PHP methods, this is perfectly feasible. However they also claim to restore your code if it was encrypted with ioncube and Zend's encoders, which, not having tried them, but knowing the author of both products reasonably well, I have a few doubts about.

He mentions what most of the encoders on the market do to accomplish their protection (the translation into bytecodes) and what some of the potential problems with converting the bytecodes back to PHP would be. There's on piece of software he mentions ("Derick's VLD"), but that's only really useful because it dumps back the opcodes in a readable format.

On the SitePoint PHP blog today, Harry Fuecks talks about some of the options to integrate PHP with Java - the Caucho updates specifically.

From this post on the server side it seems Caucho have added PHP support to their Resin Java App server.

There are a number ways to integrate with Java, by which I mean PHP-the C version.

What's interesting about what Caucho seem to have done is, rather than integrate with PHP-C, they've written their own parser for PHP scripts in Java, from which they generate Java byte code for execution. I say "seem" because I've only glanced at the source and found a convincing-looking PHP parser in there. He also points out a wiki entry with some more information on it...

John Lim has a new post on PHPEverywhere today with a look at a listing of a few PHP compilers that are up and coming.

The number of implementations of PHP continue to rise and rise. [...] I am excited about all these implementations. Most computationally intensive compiler benchmarks have shown a 5-10 times speedup over mod_php. Perhaps it is only a matter of time before we see a JIT compiler for PHP to Intel opcodes, built into mod_php...

Some of the ones mentioned include:

• Caucho's PHP5 to Java bytecode compiler
• Pint, a PHP to Parrot compiler
• Roadsend, a commercial PHP to binary compiler

He also speculates on the things that might be causing a slow uptake of these compiler technologies, things like: "is PHP fast enough?" and "Not all PHP extensions/libraries are available on all systems"...