FuelPHP Forums

ipsod

For relations, I have a dropdown() function in the foreign model, so when creating a form for or validating a product, for example, I call \Manufacturer\Model::dropdown().

This is my dropdown() function, which I grabbed from one of Harro Verton's posts:


    // Method to get a dropdown, called by a foreign model.
    public static function dropdown()
    {
        // so we can cache the results
        static $dropdown = array();

        // get the data if needed
        if (empty($dropdown))
        {
            $dropdown = \DB::select(static::$keyfield, static::$datafield)->
                 from(static::table())->
                 execute()->
                 as_array(static::$keyfield, static::$datafield);
            empty($dropdown) and $dropdown = array();
        }

        return $dropdown;
    }

Is there a significant performance cost for doing this?
Is it still significant when using APC or some other performance enhancer?

Harro

Everything has a performance cost.

However, the cost of loading and parsing a class is neglectable compared to the time needed to run the query.

On the other hand, over-optimized spaghetti code has a huge maintenance cost due to it's complexity, deviation of the KISS principle and the principe of loose-coupling and seperation of concerns.

To give a comparison: the additional cost of a faster dedicated server at the hosting company I use compares on a yearly basis to about 2 hours of my work.

ipsod

Thank you. I have a hard time knowing when I'm over-optimizing and tend to do it often. I'm not always optimizing for hardware, but sometimes just trying to make everything automatic.

Are there any rules of thumb or maxims I need to learn? Is it just a matter of having enough experience/skill to know better?

Harro

The only rule I use is "optimize only when you must".

Start with a proper design of your application. It should have a correct database schema, code should follow the DRY (don't repeat yourself) and KISS (simple) principles, and not have any tight coupling.

I find it helps to have a development environment that isn't too fast, you'll notice performance issues earlier. Most dev's use state of the art hardware, think everything runs fine, and then are suprised when it runs in production on a machine with less power and more concurrent users. After which the optimisation panic starts...

Once you notice an issue, profile it, and addess the major issues you find, but don't over optimize.

There are some obvious exceptions. For example, if your application uses an RBAC model stored in the database for user permissions, it makes sense to immediately develop this with a caching mechanism, as it would hit the database with complex queries on every request.

FuelPHP Forums

Ask your question about FuelPHP in the appropriate forum, or help others by answering their questions.

Howdy, Stranger!

Categories

In this Discussion