On Rdavid.net there's a post with the results from some tests run on hos much memory the Zend Framework and Doctrine used both with and without the APC caching.

I have decided to run with Doctrine as my Domain Model in Zend Framework projects. The thing is, if I'm going to commit to this, I need to know that applications I build in the future with the Zend Framework while using Doctrine as an integral part of the Model layer will not take performance hits from things like memory usage. With Doctrine doing a _lot_ of magic, I thought that this would be something that I wanted to see for myself. 4MB Memory to execute a simple Query?!?! Ffffff#$#!!!!

He includes the code for his testing procedure - creating a basic Doctrine object and running a "fetchOne" query and measuring the memory consumption with the memory_get_usage function. His results with the APC caching came out faster by about 60-70 percent.

Since the Symfony framework project has such tight integration with both the Propel and Doctrine ORM layers, they thought they'd share some statistics on the usage of both as mapped through the stats from their Jobeet tutorial.

As for any Open-Source community, it's not easy to find metrics that tell you what people use and how they use it. You can measure the number of tickets for a specific feature, count the number of people asking for help on Propel or Doctrine. But for the Propel vs Doctrine question, we have two more reliable metrics.

As is shown in this graph of the total Jobeet traffic in 2009, Doctrine is winning by a long shot. That's not to say that you can't still use Propel is that's what you and your application are using, this is just showing the overall popularity of each of the ORMs.

Derick Rethans has a new post today talking about using the Xdebug tool to track the memory usage in your application with some of its profiling capabilities, specifically function traces.

Function traces log every include, function call and method call to a file. If the xdebug.trace_format setting is set to "1" then the trace file is an easy-to-parse tab separated format. The information that is logged includes the time-index when the function started and ended, and it also contains the amount of memory that was in use when entering the function, as well as when leaving it.

He's written up a sample script (you can grab it from the Xdebug CVS server) that you can run on a file and push all ouf the output to the trace file for easy parsing. The script reads in the file and displays the results in a nice format on the command-line (easily adaptable for a web frontend).

On his blog today Giorgio Sironi has posted a look at some advanced usage of the Zend_Form component of the Zend Framework:

If you have ever duplicated a form for editing and adding a new entity to your application, or have felt the pain to manually populate text inputs, you now know being able to reuse a form is a killer feature and in fact many php frameworks provide a form library. Today I have gathered from my experience some know-how I have learnt while taking the Zend_Form component to its limits.

He talks about decorators, ignored elements, subforms, the Dojo javascript functionality and the captcha feature of the Zend_Form component.

This new post to the PHPClasses.org blog take a look at some of the new features that will be included in the PHP 5.3 release (coming soon to a web server near you!) by way of an interview with Lukas Smith.

his article presents an interview with core PHP developer Lukas Kahwe Smith that has pushed many of the new features of PHP 5.3 as release manager. Lukas talks about PHP 5.3 new features such as lambda functions, closures and PHAR support. He also explains what are traits, which for now it is a feature that was left out of PHP 5.3. He also talks about future PHP 5.x and PHP 6, as well how anybody can help in the development of PHP to make it come out faster.

They talk about the PHP.net wiki, briefly touch on the PHP 5.3 feature updates, performance/memory usage in the new version, Lambda functions, closures and PHAR and what's to come with PHP 6.

Debugging resources being used by your script has always been a pain, and many developers have come up with their own libraries to handle the process. Ryan Campbell has his own entry in the category - the PHP Quick Profiler.

In our company, code reviews play an integral part in the development process for making quality software. We opt for a mentor style approach with Wufoo, where a developer works on a segment for a period of time and then passes it up to a more experienced developer for review.

[...] To reduce this repetition of checking the same requirements over and over], we invested some time creating something we've called the PHP Quick Profiler-we call it PQP for short. It's a small tool (think Firebug for PHP) to provide profiling and debugging related information to developers without needing them to add a lot of programmatic overhead to their code.

The post gives several screenshots of the tool in action and code to get you up and running quickly. The Profiler can keep track of memory usage, "runaway" includes, execution time and database activity. There's also an online demo so you can try it out yourself.

Here's the link to the latest version's download.

InfoWorld.com has asked a Buggles-inspired question about PHP and Java and how they influence each other's use - "Did PHP kill the Java radio star?"

Zend's CEO makes a claim that PHP is disrupting Java. Not only would I beg to differ, I think the use of Java and PHP (and other dynamic scripting languages) together is much more interesting to customers than an "either/or" discussion. [...] To argue that PHP is disrupting Java usage is, if you ask me, missing the point.

They suggest that PHP and Java really aren't in any kind of competition. Instead, they're separate tools that should be applied correctly when the need fits their skills. If anything, PHP has encouraged Java, especially with the creation of a Java-to-PHP bridge that lets them talk back and forth.

Sebastian Bergmann has posted a real world benchmark as justification for moving from a PHP 4 to PHP 5 environment - evidence from Flickr's change.

Benchmarks such as the PHP / GCC / ICC Benchmark I posted quite a while ago on this blog are synthetic. They test "raw bytecode execution" speed that cannot be translated into real-world situations per se. Flickr recently migrated from PHP 4 to PHP 5. And here are their real world numbers.

The graph shows a dramatic drop in processing needed (CPU usage) at the moment they made the switch over from PHP4 to PHP5.The system processing usage stayed about the same (system processes like logging and memory handling) but the user CPU usage (like what the web server would use) saw an immediate change by almost twenty percent.

Correcting himself from some previous comments concerning PHP 5 versus PHP 4 usage among developers, Marco Tabini has posted something new to his blog with some updated stats.

In the past, I have not been shy about sharing my opinion that the impending death of PHP 4 would have wreaked all sorts of havoc over the PHP world. I am glad to say that I've been wrong - dead wrong, in fact - and that I have never been as happy to be so far off the mark before.

According to a readers survey that the php|architect magazine ran (about a year ago even) PHP 5 is stronger than ever, taking up well over sixty percent of the usage with only a small part still hanging with PHP 4. Check out his graph for the full rankings.

Damien Seguy has passed on the latest PHP statistics for October 2008 on the nexen.net site. Here's a few highlights:

• This was the last month of PHP 4 dominance
• PHP 5 tops PHP market share with 47.50% usage
• PHP 4.4.9's usage is moving even lower

The full stats (including graphs) can be found here and the evolution stats are here.