in reply to Re: Re: performance - loops, sub refs, symbol tables, and if/elses
in thread performance - loops, sub refs, symbol tables, and if/elses

I wouldn't categorise OO-Perl as all-caps-with-emphasis slow. In practical terms, it's just an extra argument to your functions, which just happen to be in a different namespace.

Here's a simple benchmark that reveals a maybe 6-10% penalty for using OO without any optimizations. 
use warnings;
use strict;

use Benchmark qw[ cmpthese ];

package Banana;

sub new {
        my $class = shift;
        return bless({ @_ }, $class);
}

sub peel {
        my ($self) = @_;
        my $x;

        foreach (keys %$self) { $x += $self->{$_}; }

        $x;
}

package main;

sub peel {
        my ($banana) = @_;
        my $x;

        foreach (keys %$banana) { $x += $banana->{$_}; }

        $x;
}

cmpthese(10_000,{
        oo_peel => sub { my $banana = Banana->new( foo => 10, bar => 1
+5);
                                for (1..250) { $banana->peel(); } },
        pr_peel => sub { my $banana = { foo => 10, bar => 15 };
                                for (1..250) { peel($banana); } },
});

[download]
I've found that while using an object-oriented approach might be slow at the outset, having a good framework does make optimising easier.

Replies are listed 'Best First'.
Re: Re^3: performance - loops, sub refs, symbol tables, and if/elses
by jdporter (Paladin) on Dec 17, 2002 at 19:21 UTC
    I wouldn't categorise OO-Perl as all-caps-with-emphasis slow.
    Well, I would, because it is. It is more than just an extra argument to your functions. It is (possibly inherited) method lookup. That's where the real performance hit comes from. If you have very simple classes, with no inheritance, the penalty is minimal, but it still exists.

    jdporter
    ...porque es dificil estar guapo y blanco.

[reply]
      As far as I can tell, Perl caches any inherited function lookups once they are performed, so after the first call, subsequent calls are just as fast as if they were in the class package. In the majority of cases, you can hardly tell the difference.

      Using object-oriented methods incurs a small but acceptable penalty, and considering practical benefits, it's often worth the expense. An object-oriented approach is not always the most effective, admittedly, but it's often close enough that the differences are often a matter of preference.
[reply]
        Using object-oriented methods incurs a small but acceptable penalty,
        What's acceptable is really for each individual engineer to decide. While I agree with your general point, this OP sounds like he wants the fastest possible solution. And that, unfortunately, means avoiding OO.

        jdporter
        ...porque es dificil estar guapo y blanco.

[reply]

In Section Seekers of Perl Wisdom