in reply to Re: Battling with OOP performance
in thread Battling with OOP performance

Thanks for your answer. I've already had a look at Class::DBI, and it's a great module. It doesn't help much on the performance in my case, though, as I already cache database connections and queries.

Due to the complexity of my application I wasn't able to show that in the code I wrote in my original message. I see now that I should have "warned" you about that. :-)

Replies are listed 'Best First'.
Re: Re: Re: Battling with OOP performance
by perrin (Chancellor) on Sep 05, 2003 at 15:47 UTC
    Sounds like the real performance battle here is with the database. You should reconsider Class::DBI. It has a few solutions to this situation.

    The first is lazy loading. You can have it query for all of the Persons attached to a Group, and it will create objects that just hold the ID. When you try to access another property on one of these, it does a query to load the other objects. This is good if you query for all of them, but only use the other properties of a few.

    You could also just list the columns you want as essential columns on Person (i.e. always fetch these when getting a Person from the database) and then set up a "has_many" association from Group which automatically does the join and gets the essential columns all in one query.

    Finally, if you need something special, you can add a custom SQL query to Person that finds all the information you want in one shot and Class::DBI handles all the work of creating the objects. It would look something like this:

    package Person; ... __PACKAGE__->set_sql(by_group => q/ SELECT person_id, firstname, lastname FROM person WHERE group_id = ? /); package Group; ... sub get_members { my $self = shift; Person->search_by_group($self); }
Re: Re: Re: Battling with OOP performance
by monsieur_champs (Curate) on Sep 05, 2003 at 14:41 UTC

    Dear Evil Attraction
    I've read at the merlyn's "Learning Perl Objects, References & Modules" that OO Perl (as any other OO system or language) gives up on performance in favor of readability and (mainly) code reusability.

    IMHO, if you're looking for performance improvements, chopping the OO implementation will not be that useful. Maybe you should benchmark your application and determine where are the bottlenecks you need fix. Try to optimize the bottlenecks as the main way to improve performance, and always take into account the performance cost intrinsic to object-oriented implementations.

    Good luck!

    =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
    monsieur_champs