Derick Rethans has a new post to his site today about MongoDB cursors in PHP when using the PHP driver and how it handles pulling data from the server.

Recently I was asked to improve the MongoCursor::batchSize documentation. This began an indepth investigation in how the PHP driver for MongoDB handles pulling data that's been queried from the MongoDB server. Here are my findings.

He talks about the cursor that's created when a "find" call is made and how you can add on additional options (via other methods on the cursor) to its execution. He also covers how you can set your own batch size, using limit to only fetch a certain number of results and combining the two to make for more memory efficient, yet complete, returned data sets.

In this new post to his blog Larry Garfield tries to dispel a common misconception in the PHP development world - that the readfile function should be considered harmful and can cause memory issues in your code.

If you're like me, you've probably read a dozen or two articles about PHP performance in your career. Many of them are quite good, but some are simply flat out wrong, or misinformed. One of the old truisms that has been repeated for as long as I can recall is "don't use readfile() if you have big files, because it reads the whole file into memory and your server will explode." [...] There's just one problem with that age-old truism: It's not true.

He created some benchmarks to illustrate the differences between several of the common methods for working with files via the fread, fpassthru, stream_copy_to_stream and of course readfile. He reports the results based on the runtime and the peak memory usage and noted, ironically, that while the times varied slightly, the memory consumption was exactly the same for all of the approaches. Since there's no real reason not to use "readfile", he looks at three reasons why there might be this stigma attached to it (including the issues that could come up with output buffering enabled).

In this new post to his blog Joshua Thijssen describes something that can help when processing large amounts of data (like, in his example, the text of a book) to search through the information and find if a certain piece of data is in the set - a bloom filter.

Most of my co-workers never really heard of bloom filters, and I'm continuously need to explain what they are, what their purpose is and why it's a better solution than other ones. So let's do an introduction on bloom filters. [...] Bloom filters have the property of being exceptionally fast AND exceptionally small compared to other structures but it comes with a price: it MIGHT be possible that our bloom filter thinks that an element is inside our set, when it really isn't. Luckily, the reverse is not possible: when a bloom filter says something is NOT in the set, you are 100% sure that it isn't part of the set.

He explains how the filter works, noting how it's better for memory consumption and how it's possible for it to give a "maybe" response instead of ab absolute "yes" or "no". He also points out a PHP extension, bloomy that takes the hard work out of it for you.

On the UMumble blog there's a recent post looking at memory consumption in PHP applications - what PHP does for you when managing how it uses your system's memory and what you need to worry about in your code.

There is a widespread view that the ordinary PHP developer does not need to control memory management, but "controlling" and "knowing" are slightly different concepts. I will try to throw light upon some aspects of memory management when working with variables and arrays, and some interesting pitfalls of the internal optimization of PHP. As you can see, the optimization is good, but if you do not know exactly how it is optimized, you might meet the pitfalls, which can make you pretty nervous.

They talk about some of the basics - how variables are stored in hash tables and how this helps memory consumption - as well as using the memory_get_usage method to find your current consumption. This is show for both regular strings and arrays, comparing larger data (and assigning it multiple times) to simpler structures. They also mention how PHP handles memory usage in passing by reference and copying of values.

On the IBM developerWorks site today there's a new tutorial showing you how to store shared data directly to a shared memory space of your PHP application.

Once created, and given proper permissions, other processes in the same machine can manipulate those segments by: read, write, and delete. This means that an application written in C can share information with an application written in other languages, such as Java or PHP. They can all share information, as long as they can access and understand that information. [...] This article's proposal is simple, learn how to create and manipulate shared memory segments with PHP and use them to store datasets that other applications can use.

Your PHP installation will need to have been compiled with "enable-shmop" to work with the code in this tutorial. Their examples show how to use the shmop_open, shmop_write and other related functions to read, write, remove and close segments in the shared memory space. They also include an example of using the SimpleSHM library to make it easier to interact with the shared memory space as a standard storage location.

In response to a previous post benchmarking exceptions, Volker Dusch has posted some of his own thoughts and benchmarking results on the same topic.

Some days ago there was a blog post regarding php exception performance in 5.4 and the numbers got reported all over the place. The actually numbers are secondary. The main point is: Don't trust "random" stuff on the Internet when thinking about improving your application performance. You always need to measure things for your self and take care doing so! I've initially trusted the benchmark myself and disgraced the whole post saying: "Well yes, exceptions are slower than if statements but nice that they got faster".

He includes some results with a bit more standardized testing - one run with both 5.3 and 5.4 using XDebug and another with it turned off for both. His results make sense, if you think about them:

So what we learn from that? Running stuff with debugging tools is slower than not doing that. That's why we don't use xDebug in production.

Gonzalo Ayuso has a new post to his blog today looking at the performance of PHP exceptions and how it could effect your application's overall speed.

Sometimes we use exceptions to manage the flow of our scripts. I imagine that the use of exceptions must have a performance lack. Because of that I will perform a small benchmark to test the performance of one simple script throwing exceptions and without them.

His (little) benchmarking scripts are included - both looping 100000 times, one throwing an exception and the other not. The results were pretty obvious - the memory usage was about the same but the speed was about ten times faster without the exceptions (in PHP 5.3). In PHP 5.4, however, the numbers were closer as far as time to run. Obviously, unless you make super heavy use of exceptions, you're not even going to come close to something like this (micro-optimization anyone?).

On PHPMaster.com today there's a new post from Matthew Turland talking about PHP's quest for performance and some of the recent advancements that have made better performing applications even more possible.

While it's sufficient for many users, as PHP sees increased use by large sites like Wikipedia and Facebook, the ability to serve more requests on fewer servers becomes increasingly important. Some efforts have been made in this area in the last few years, both within and outside the PHP internals team. However, understanding exactly what's going on requires a bit of background both in history and concepts.

He goes through some of the origins of the PHP language (from the early days with Rasmus Lerdorf) to the fact that the PHP language itself is interpreted - complete with some of the overhead that comes with that. He also mentions various projects that have tried to compile PHP back down to C to increase performance like Roadsend, HipHop and, most recently, the HipHop virtual machine from Facebook.

In this recent blog post nikic takes an in-depth look at how large PHP arrays really are - how memory is used in the creation and management of these handy PHP variable types.

In this post I want to investigate the memory usage of PHP arrays (and values in general) using the following script as an example, which creates 100000 unique integer array elements and measures the resulting memory usage. [...] How much would you expect it to be? [...] Now try and run the above code. You can do it online if you want. This gives me 14649024 bytes. Yes, you heard right, that's 13.97 MB - eightteen times more than we estimated.

He goes into the details of PHP's memory management and breaks it down into the different totals (for 64 bit and 32 bit OSes) and details on each - zvalue_value, zvalue, cycles collector, Zend MM allocator and the buckets used to isolate one array (hash table/dictionary) from another.

What does this tell us? PHP ain't C. That's all this should tell us. You can't expect that a super dynamic language like PHP has the same highly efficient memory usage that C has. You just can't.

On the VG Tech blog today there's a new post from André Roaldseth about using PHPUnit to test PHP streams, basing the assertions on the data rather than the functionality itself.

Using the memory/temporary stream provided by php:// stream wrapper you can create a stream with read and write access directly to RAM or to a temporary file [using "php://memory"]. This gives you the possibilty to write unit tests that does not rely on a specific file, resource or stream, but rather on data provided by the test itself.

There's no specific code examples here, but you can refer to the stream wrappers section of the PHP manual for more details on this and other handy built-in streams. Once created, it can then be used just as any other stream resource can. This could be useful to provide mocks in your testing, replacing any other stream-able resource with a "memory" or "temp" placeholder.