PHP style question: "caching" object/array values in a variable?

Please save me from myself (or reassure me that I'm not being completely misguided)

I've gotten into the habit of writing code something like the following:

fu开发者_Python百科nction foo($aUserObject) {
    $theUserUID = $aUserObject->uid;
    $aDeepValue = $aUserObject->property[123][456];
    [more code, in which much use is made of $theUserUID and $aDeepValue]
}

My strategy is probably obvious: I'm taking the attitude that it's going to be easier for the PHP interpreter to handle a variable reference than to continually dig into the object to find the thing I'm interested in, so I should be getting some performance benefit. In addition, my code is perhaps a bit more bug-free and understandable (as long as I remember the meanings of the variable names), since I'm mostly writing simple variable names instead of longer and more complex object/array references where my fingers are more likely to slip. I understand that there's a price for doing this -- there are now two copies of $aUserObject->uid and $aUserObject->property[123][456] floating around, and if those values are large, the additional memory costs could add up. But I'm currently willing to pay that price in exchange for the (alleged) benefits.

Or, that's what I'm telling myself anyway, based on my naive theory of how PHP underpinnings work. But reality, especially when opcode caching tools like APC get introduced, may be a totally different matter. Any more informed opinions out there, that might push me one way or another?

Thanks!

---

I can reassure you, you're wrong when you say:

I understand that there's a price for doing this -- there are now two copies of $aUserObject->uid and $aUserObject->property[123][456] floating around, and if those values are large, the additional memory costs could add up.

Unless $theUserUID is modified or referenced, it points to the exact same memory location that the property you fetched it from.

You can even do:

$a = $b = $c = $d = $e = 'hello world!';

And it won't take any more memory than:

$a = 'hello world!';

A copy will be created in the following scenarios:

$a = 1;
$b = $a;  // $b references $a
$b = 2;   // $b is now a copy (no longer references $a)

$a = 1;
$b = $a;  // $b references $a
$c = &$b; // $b is now a copy (no longer references $a)

It's called copy-on-write.

Tip: Try debug_zval_dump and memory_get_usage and notice the refcount that increases, while the memory usage stays the same.

---

Correct me if I'm mistaken, but I believe you're wrong about something.

there are now two copies of $aUserObject->uid and $aUserObject->property[123][456] floating around, and if those values are large, the additional memory costs could add up.

There'll be another reference to the value, but it does NOT mean that it will occupy twice the amount of memory. It's like a relational database, you can add lots of references to the same element, but it's only the references themselves that will be stored more than once.

---

Code being more understandable is a big plus if you plan on maintaining it.

Of course, some routines might need more attention to memory/performance issues than others, but unless you are dealing with big amounts of data, the benefits are well worth the (possible) costs.

by the way, you can also use references:

$theUserUID = &$aUserObject->property[123][456];
$theUserUID = 'someValue'; // updates $aUserObject 

---

This seems good to me. But only as a second point.

I suggest:

1. Be sure that your code is readable and understandable (documentation, proper variable naming, codestyle guidlines, etc).
2. Search for modern standards or new one in the future in the languge (here php) and keep to it!
3. Reusablity: This is the benefit of point 1 and 2.
4. Performance issues should be discussed - but on an algorithmic/design-pattern layer and not on deep-code-basis. On the final implementation just be sure that you implement it correct.
5. Optimization: Only if some performance issues arise, than think of deep-code-optimization. But be sure that its understanable and readable. Otherwise the code gets useless in the future.