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.

Juozas Kaziukenas has posted the third part of his series looking at the powerful combination of Zend Framework and the Doctrine ORM layer.

During last two months I spent massive amount of time tweaking Doctrine ORM framework and making it to perform as fast as possible (as you might have noticed from my never ending tweets). This post is devoted to performance and efficiency, with practical tips & tricks how to reduce memory usage, make it work faster and save resources.

He's broken it up into two main parts with points underneath:

• Speed including a look at hydrators, DQL and optimization
• Memory usage and how you can optimize things that seem simple and some recommendations of tools you can use to resolve some of the trouble spots.

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 the Symfony blog today there's a new post by Fabian Lange about using the detailed logging ability of the newly released version of Propel (the database abstraction layer).

Today Propel 1.4 was released and it contains some debugging goodies. We can use the DebugPDO class to get the nifty logging into the Web Debug Panel. However some more interesting information is turned off by default by Propel.

Features include time logging, memory logging and slow query logging - all that are simple to enable in your configuration under the details for your propel connection. You can see an example of the output from the logging here.

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.

Matt Curry has posted a screencast about some of the updates that he's made to the CakePHP Debug Kit:

I've been doing some upgrades on the CakePHP DebugKit and wanted to share them with everyone. I figured doing a quick screencast would be faster then writing a post. Was I wrong. It took me like an hour to record this, even though the running time is just over two minutes.

Included in the updates is the ability to select a page from the History and get all of the statistics for that request (instead of just teh current page like it was before). You can grab this latest version from his page on github: http://github.com/mcurry/debug_kit/tree/master.

Sometimes finding that one spot in your code that's geting bloated and consuming at majority of your memory can be a bit difficult. Antony Dovgal has proposed one solution in a new post to his blog - the memtrack extension for from PECL.

We needed to locate where most of the memory is allocated in our scripts (as some of them became too memory hungry), so I've created memtrack extension. This extension helps us to see unusually big memory allocations in production code.

The extension logs memory usage information out to the standard error log file (however that'd defined on your system) and comes with a few configuration options. These let you control things like a "soft limit" at which to report the usage problems, the ability to ignore certain functions that you might know will cause a high load and and "vm_limit" setting that can help if your script is leaking memory at the end of its run.

On his blog today Gopal Vijayaraghavan has posted about the release of the latest version of the APC sofware (Alternative PHP Cache) - version 3.1.2.

Finally, after nearly a year of work, it's into a release. Some new stuff has sneaked into it undocumented, that people might find interesting - apc.preload_path would be one of them. The backend memory allocation has been re-done - the api part by me and the internals by shire. There's a hell of a lot of new code in there, both rewritten and added. Tons of php4 cruft removed, php5 stuff optimized, made more stable, then less stable, made faster, then applied brakes. Made leak-proof, quake-proof and in general, idiot-proof. So, on & so forth.

To show the difference, he includes a diff of the current version against the previous - 68 files changed, 3255 insertions and 5545 deletions.

In looking to test his fputscsv functionality, David Otton found a simple way to measure its performance by using streams.

Then I realised I could use PHP's (fairly) new IO streams to dump the function's output to a temporary buffer, and read it back in for comparison. Not perfect, but it removes concerns about file mutexes, permissions, unique filenames, etc. and speeds up the tests, as they never touch disc.

He uses a custom stream and points it to php://memory to store and read the data from. Code is included in the post as well as example usage. It runs an assert that the value pushed into another memory chunk is the same as the first one (ensuring that the results of his fputcsv calls are valid).