10.04.2018 Views

Doctrine_manual-1-2-en

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Chapter 28: Improving Performance 365<br />

$results = $q->execute(array(), <strong>Doctrine</strong>_Core::HYDRATE_NONE);<br />

You will need to print the results and find the value in the array dep<strong>en</strong>ding on your DQL<br />

query:<br />

print_r($results);<br />

Listing<br />

28-12<br />

In this example the result would be accessible with the following code:<br />

$total = $results[0][1];<br />

Listing<br />

28-13<br />

There are two important differ<strong>en</strong>ces betwe<strong>en</strong> HYDRATE_ARRAY and HYDRATE_NONE which<br />

you should consider before choosing which to use. HYDRATE_NONE is the fastest but the<br />

result is an array with numeric keys and so results would be refer<strong>en</strong>ced as<br />

$result[0][0] instead of $result[0]['my_field'] with HYDRATE_ARRAY. Best<br />

practice would to use HYDRATE_NONE wh<strong>en</strong> retrieving large record sets or wh<strong>en</strong> doing<br />

many similar queries. Otherwise, HYDRATE_ARRAY is more comfortable and should be<br />

preferred.<br />

Bundle your Class Files<br />

Wh<strong>en</strong> using <strong>Doctrine</strong> or any other large OO library or framework the number of files that<br />

need to be included on a regular HTTP request rises significantly. 50-100 includes per<br />

request are not uncommon. This has a significant performance impact because it results in a<br />

lot of disk operations. While this is g<strong>en</strong>erally no issue in a dev <strong>en</strong>vironm<strong>en</strong>t, it's not suited for<br />

production. The recomm<strong>en</strong>ded way to handle this problem is to bundle the most-used classes<br />

of your libraries into a single file for production, stripping out any unnecessary whitespaces,<br />

linebreaks and comm<strong>en</strong>ts. This way you get a significant performance improvem<strong>en</strong>t ev<strong>en</strong><br />

without a bytecode cache (see next section). The best way to create such a bundle is probably<br />

as part of an automated build process i.e. with Phing.<br />

Use a Bytecode Cache<br />

A bytecode cache like APC will cache the bytecode that is g<strong>en</strong>erated by php prior to executing<br />

it. That means that the parsing of a file and the creation of the bytecode happ<strong>en</strong>s only once<br />

and not on every request. This is especially useful wh<strong>en</strong> using large libraries and/or<br />

frameworks. Together with file bundling for production this should give you a significant<br />

performance improvem<strong>en</strong>t. To get the most out of a bytecode cache you should contact the<br />

<strong>manual</strong> pages since most of these caches have a lot of configuration options which you can<br />

tweak to optimize the cache to your needs.<br />

Free Objects<br />

As of version 5.2.5, PHP is not able to garbage collect object graphs that have circular<br />

refer<strong>en</strong>ces, e.g. Par<strong>en</strong>t has a refer<strong>en</strong>ce to Child which has a refer<strong>en</strong>ce to Par<strong>en</strong>t. Since many<br />

doctrine model objects have such relations, PHP will not free their memory ev<strong>en</strong> wh<strong>en</strong> the<br />

objects go out of scope.<br />

For most PHP applications, this problem is of little consequ<strong>en</strong>ce, since PHP scripts t<strong>en</strong>d to be<br />

short-lived. Longer-lived scripts, e.g. bulk data importers and exporters, can run out of<br />

----------------- Brought to you by

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!