The scenario was simply this: I had to load a JPEG (1024 x 768 pixels in size), create a thumbnail based on that, and output the thumbnail.

During coding I profiled and checked the memory use after each GD operation to see which method had the greatest impact on RAM.

The process the scripts took was extremely simple. It would just load a JPEG, create a new thumbnail 200x200 in size and then destroy the original JPEG image resource. What I was looking at most was how much memory was freed-up after calling the imagedestroy() function on the original JPEG.

Straight Procedural

The first technique was simply to use straight variables, not a single class or function in sight. This is just concept code, not production ready obviously, but it'll show you what is going on:

[geshi lang=php] $jpg = imagecreatefromjpeg('tree.jpg'); $output = imagecreatetruecolor(200, 200); imagecopyresampled($output, $jpg, 0, 0, 0, 0, 200, 200, 400, 400); imagedestroy($jpg); [/geshi]

Using this technique (i.e. straight procedural code, no classes, no functions) the memory use after the imagedestroy() call was as expected:

Init: 262 KB
Load JPEG: 4.1 MB
Create Thumbnail: 4.4 MB
Destroy JPEG: 1.5 MB

Storing the image resource in an Object array

However, as this code was part of a much larger project, I obviously coded it all using objects. I created an 'image object' that I could pass around (this is using PHP 5.2.2, so no PHP 4 pointer messing required). At its most simplified level the object looked like this:

[geshi lang=php] class imageObject { protected $jpg = array(); public function setIt ($image_data) { $this->jpg['data'] = $image_data; } public function getHandle () { return $this->jpg['data']; } public function destroy () { return imagedestroy($this->jpg['data']); } public function update ($new) { $this->jpg['data'] = $new; } } [/geshi]

I could then pass the object to the 'thumbnail' method, which could get the image resource handle it required for the original, create the new one, destroy the original and then update it with the thumbnail.

This all worked fine, but the amount of memory still in use after calling imagedestroy was staggering:

Init: 262 KB
Load JPEG: 4.1 MB
Create Thumbnail: 4.4 MB
Destroy JPEG: 3.4 MB

In short, destroying what is nearly 4MBs worth of image data resulted in only 1MB of memory being freed-up after the call.

Storing the image resource in an Object var

So I re-wrote the object to use a local var instead of an array (I was using an array in the first place because I held lots of other values as well, such as the image width / height, etc). Again the very simplified code was:

[geshi lang=php] class imageObject { protected $data; public function setIt ($image_data) { $this->data = $image_data; } public function getHandle () { return $this->data; } public function destroy () { return imagedestroy($this->data); } public function update ($new) { $this->data = $new; } } [/geshi]

This one single change, from holding the image resource handle in a var instead of an array caused the memory use to drop down again quite significantly after calling destroy():

Init: 262 KB
Load JPEG: 4.1 MB
Create Thumbnail: 4.4 MB
Destroy JPEG: 2.8 MB

So still nowhere near as good as the procedural version, it was significantly better than before.

Here is how they all stack-up in graph form:

I'm still surprised at the difference between procedural and object based storage of the image resource handle. The difference between the two is a staggering 100% increase in memory use. But even more surprising was finding that PHP would hold onto another 600KB worth of memory just for using an array instead of a var.

This is obviously due to the way in which PHP is managing the data internally, and I'm sure there are good reasons as to why it happens like this (and if you know them, please post and tell me!).

I guess the moral of this investigation is - if you are going to store your image resources in an object, do it in a var and not an array. But if you can help it, don't use an object at all.

autoload grief

If you use the __autoload() function to control class loading in a large-scale project then be aware of the following:

autoloaded classes and classes that are required from within other classes, do not free-up memory after image resources destruction. In our example above if the imageObject() class was autoloaded, then the memory used after the imagedestroy() is called will be exactly the same as prior to it. In other words it's as if PHP doesn't know how to free-up the memory after deleting a resource, when the resource exists within an autoloaded class, or a class that was required within another class.

If you simply move the 'require' statement outside of the class, or don't autoload it, then memory is freed as expected.

Update: 22nd May

Due to various comments claiming the results are incorrect, here is the source code used to test. Also I have now run this code on a Windows server (with 5.2.2) and a FreeBSD server (with 5.2.1) and the memory use values definitely differ.

Change the image path as required.

Procedural test

[geshi lang=php] $picture = "/usr/www/users/corephp/tree.jpg"; $mem['init'] = number_format(memory_get_usage(true), 0); $jpg = imagecreatefromjpeg($picture); $mem['load jpeg'] = number_format(memory_get_usage(true), 0); $output = imagecreatetruecolor(200, 200); $mem['create 200x200'] = number_format(memory_get_usage(true), 0); imagecopyresampled($output, $jpg, 0, 0, 0, 0, 200, 200, 400, 400); $mem['resample'] = number_format(memory_get_usage(true), 0); imagedestroy($jpg); $mem['destroy'] = number_format(memory_get_usage(true), 0); //unset($jpg); //$mem['unset'] = number_format(memory_get_usage(true), 0); print_r($mem); [/geshi]

The above running on Windows leaves me with a 'destroy' value of 1,572,864 bytes. Running on FreeBSD I'm left with 1,048,576 bytes (500KB less). Is this a result of the way PHP works on Windows vs. FreeBSD, or the way in which memory_get_usage() reports back on different platforms?

Someone in the comments said that unset() is faster and leaves more memory free, so I tried running with that and they were right - comment out the imagedestroy() in the code above, and uncomment unset() and the free memory (on FreeBSD) was 786,432 bytes, considerably less than using imagedestroy () on its own. Performing an imagedestroy() followed by an unset() makes *no difference at all* though, which interests me as to where that 'extra' 260KB has gone?

Class Test - Observation 1

[geshi lang=php] class image_test_1 { protected $img; public function __construct () { $picture = "/usr/www/users/gamcreat/tgcadmin.com/tree.jpg"; $mem['init'] = number_format(memory_get_usage(true), 0); $jpg = imagecreatefromjpeg($picture); $mem['load jpeg'] = number_format(memory_get_usage(true), 0); $this->img = $jpg; print_r($mem); } public function scale () { $mem['start thumb'] = number_format(memory_get_usage(true), 0); $output = imagecreatetruecolor(200, 200); $mem['create 200x200'] = number_format(memory_get_usage(true), 0); imagecopyresampled($output, $this->img, 0, 0, 0, 0, 200, 200, 400, 400); imagedestroy($this->img); //unset($this->img); $this->img = $output; $mem['update'] = number_format(memory_get_usage(true), 0); print_r($mem); } } $c = new image_test_1(); $c->scale(); [/geshi]

The above code gives me a final result of 1,048,576 bytes after the last update on FreeBSD, which is the same as the Procedural version (because the image resource is contained within the same class). Interestingly the 'unset' over 'imagedestroy' benefit no longer applies. Uncomment 'unset' in the code above and I get the exact same result as using imagedestroy() on its own. On a Windows server I'm left with 1,310,720 bytes at the end.

Class Test 2 - Placing the image resource in another object

Here is where the main differences begin. Here is an 'image_object':

[geshi lang=php] class image_object { public $data = false; public function __construct ($image_data) { if (is_resource($image_data) && get_resource_type($image_data) == 'gd') { $this->data = $image_data; return true; } else { return false; } } public function get () { return $this->data; } public function destroy () { if (is_resource($this->data) && get_resource_type($this->data) == 'gd') { return imagedestroy($this->data); } else { return false; } } public function replace ($new_resource) { if (is_resource($new_resource) && get_resource_type($new_resource) == 'gd') { $this->destroy(); $this->data = $new_resource; return true; } else { return false; } } } [/geshi]

Pretty standard stuff. If we now combine this new object class with the image_test class below, watch the memory difference:

[geshi lang=php] class image_test_2 { protected $img; public function __construct () { $picture = "/usr/www/users/gamcreat/tgcadmin.com/tree.jpg"; $mem['init'] = number_format(memory_get_usage(true), 0); $jpg = imagecreatefromjpeg($picture); $mem['load jpeg'] = number_format(memory_get_usage(true), 0); $image_object = new image_object($jpg); $this->img = $image_object; print_r($mem); } public function scale () { $mem['start thumb'] = number_format(memory_get_usage(true), 0); $output = imagecreatetruecolor(200, 200); $mem['create 200x200'] = number_format(memory_get_usage(true), 0); imagecopyresampled($output, $this->img->get(), 0, 0, 0, 0, 200, 200, 400, 400); $this->img->replace($output); $mem['update'] = number_format(memory_get_usage(true), 0); print_r($mem); } } $c = new image_test_2(); $c->scale(); [/geshi]

Now on Windows I'm left with 2,359,296 bytes used at the end. On FreeBSD I'm with 1,572,864. The image resource is updated properly, the original is destroyed, everything works the way it should. It's just interesting to see the memory differences in play here.

Obviously there is overhead involved in using objects within PHP, but I would have thought that destroying the resources used by an image would do just that, destroy them, regardless of where this happens (function, class, procedure). This may well be what is happening, perhaps the memory left over is caused by PHP having to resize the memory allocation for the object? If you know, please post below.