views:

90

answers:

2

I was reading this page - http://www.hm2k.com/posts/50-php-optimisation-tips-revisited

And one of the recommendations was to avoid using Magic Methods, cited from a Zend Performance PDF which gives no reason for its recommendation to avoid them.

After some Google searching (and winding up here to an unrelated question) I wondered if anyone had any reccomendations on that front?

I use __get() alot in my code, usually to save variables that I don't always use e.g.

I may have a table with name, desc, category_id, time_added

My get would look something like this:

public function __get($name) {
    switch($name) {
        case 'name':
        case 'desc':
        case 'category':
        case 'time_added':
            $result = do_mysql_query();
            $this->name = $result['name'];
            $this->desc = $result['desc'];
            $this->category = $result['category'];
            $this->time_added = $result['time_added'];
            return $this->{$name};
        break;
        default:
            throw Exception("Attempted to access non existant or private property - ".$name);
    }
}

This seems like a great way to do things as I only ever get something from the database if it's needed and I can refence things like $article->time_added rather than fiddling around with arrays.

Would this be considered bad practice and an extra load on the server?

Often I will extend classes with magic methods and do something like this if the child class doesn't match something in a get.

public function __get($name) {
    switch($name) {
        case 'name':
        case 'desc':
        case 'category':
        case 'time_added':
            $result = do_mysql_query();
            $this->name = $result['name'];
            $this->desc = $result['desc'];
            $this->category = $result['category'];
            $this->time_added = $result['time_added'];
            return $this->{$name};
        break;
        default:
            return parent::__get($name);
    }
}

Would this be bad practice and bad for performance? The maximum number of levels I have when extending magic methods is three.

+4  A: 

It's true, they are slower... but the difference is so tiny that speed vs code is a factor. Is it worth worrying about the difference for quicker development and maintenance?

See http://www.garfieldtech.com/blog/magic-benchmarks for stats

Ashley
+1: You can't overvalue that sentiment. Remember, `Premature Optimization Is The Root Of All Evil`... If you spend all of your time worrying about the tiny speed differences, you'll never get anything done. Build it the way that works for you, and then **if** you have problems, refactor from there. But the biggest performance improvement that you can make is the transition from a non-working state to a working one. Everything else pales in comparison...
ircmaxell
Cheers the link is really helpful and your point is very true, it's very difficult not to get caught up in wanting prefect code and never actually releasing any of it :D
Rob
IMHO maintainable code is WELL more important than high performance code. Think about it. It's cheaper to throw more hardware at a problem than it is throwing more developers at it. That's one reason that PHP is so popular... Now, there's always a trade-off, so I'm not recommending ignoring performance, but don't try to micro-optimize if you don't know if a problem exists...
ircmaxell
A: 

Consider using array accessors.

class Record implements ArrayAccess {

    /**
     * @see ArrayAccess::offsetExists()
     *
     * @param offset $offset
     */
    public function offsetExists($offset) {

    }

    /**
     * @see ArrayAccess::offsetGet()
     *
     * @param offset $offset
     */
    public function offsetGet($offset) {
        //fetch and cache $result

        return $result[$offset];
    }

    /**
     * @see ArrayAccess::offsetSet()
     *
     * @param offset $offset
     * @param value $value
     */
    public function offsetSet($offset, $value) {

    }

    /**
     * @see ArrayAccess::offsetUnset()
     *
     * @param offset $offset
     */
    public function offsetUnset($offset) {

    }
aularon
And that's different how? You're just swapping four magic methods for four other magic methods...
ircmaxell
@ircmaxell Interface methods are not magic methods. Though I cannot backup with numbers, I claim these will run faster than relying on interceptors
Gordon
@Gordon: It's slower, check the link in the above answer. And yes, while it's not a "magic method" in the strict sense, it is magic in the sense that the interface enables magic-like functionality (the ability to use core functions and language constructs on the object)...
ircmaxell
@ircmaxell if you put it this way, then yes, that's a good point.
Gordon