in reply to Battling with OOP performance

I'm not sure how it fares performance wise, but Class::DBI does much of what your code does, and allows you to write your code in a more abstract fashion, in that you only declare the columns, and the accessors etc. are created automagically.

One thing that might or might not have a positive influence on the performance might be that Class::DBI inherits from Ima::DBI and thus uses prepared statements (and can use placeholders). At least this approach is safer than manually inserting values into queries, as no quoting errors can arise (and values with "'" in them cause no problems either).

For the construction of many objects from a query, Class::DBI uses a mechanism very similar to your mechanism, so I doubt that there will be much gain from that side, but it implements connection caching and query caching, two things that you don't - but I don't know if your performance will benefit from that.

perl -MHTTP::Daemon -MHTTP::Response -MLWP::Simple -e ' ;    # The  
$d = new HTTP::Daemon and fork and getprint $d->url and exit;#spider
($c = $d->accept())->get_request(); $c->send_response( new   #in the
HTTP::Response(200,$_,$_,qq(Just another Perl hacker\n))); ' #  web

[download]

Replies are listed 'Best First'.
Re: Re: Battling with OOP performance
by Evil Attraction (Novice) on Sep 05, 2003 at 11:50 UTC
    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. :-)
[reply]
      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);
}

      [download]
[reply]
[d/l]

      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

[reply]

In Section Seekers of Perl Wisdom