Re^4: Which, if any, is faster? (20% faster/ 40% smaller)

I read the following as array-based objects are 20% faster and ~~70%~~ 40% smaller than the hash based equivalent for little extra effort and no loss of clarity.

#! perl -slw
use strict;

package ArrayBased;

use constant {
    CLASS    => 0,
    SELF    => 0,
    FIRST    => 0,
    SECOND    => 1,
    THIRD    => 2,
    FOURTH    => 3,
    FIFTH    => 5,
};

sub new {
    return bless [ qw[ one two three four five ] ], $_[CLASS];
}

sub method {
    (undef) = $_[SELF][FIRST];
    (undef) = $_[SELF][SECOND];
    (undef) = $_[SELF][THIRD];
    (undef) = $_[SELF][FOURTH];
    (undef) = $_[SELF][FIFTH];
    $_[SELF][FIRST] = 1;
    $_[SELF][SECOND]= 2;
    $_[SELF][THIRD] = 3;
    $_[SELF][FOURTH]= 4;
    $_[SELF][FIFTH] = 5;
}

package HashBased;

sub new {
    my( $class ) = @_;
    return bless {
        FIRST    => 'one',
        SECOND    => 'two',
        THIRD    => 'three',
        FOURTH    => 'four',
        FIFTH    => 'five',
    }, $class;
}

sub method {
    my( $self ) = @_;
    (undef) = $self->{FIRST};
    (undef) = $self->{SECOND};
    (undef) = $self->{THIRD};
    (undef) = $self->{FOURTH};
    (undef) = $self->{FIFTH};
    $self->{FIRST}  = 1;
    $self->{SECOND} = 2;
    $self->{THIRD}  = 3;
    $self->{FOURTH} = 4;
    $self->{FIFTH}  = 5;
}

package main;
use Benchmark qw[ cmpthese ];
use Devel::Size qw[ size total_size ];

cmpthese -1, {
    arrayBased => q[
        my $o = new ArrayBased;
        $o->method;
    ],
    hashBased => q[
        my $o = new HashBased;
        $o->method;
    ],
};

print "ArrayBased bytes: ", total_size( ArrayBased->new() );
print " HashBased bytes: ", total_size( HashBased->new() );

__END__
P:\test>462336
              Rate  hashBased arrayBased
hashBased  48505/s         --       -16%
arrayBased 57853/s        19%         --

ArrayBased bytes: 220
 HashBased bytes: 373
[download]

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.

Comment on Re^4: Which, if any, is faster? (20% faster/ 40% smaller) Download Code

Replies are listed 'Best First'.
Re^5: Which, if any, is faster? (20% faster/ 40% smaller) by adrianh (Chancellor) on Jun 02, 2005 at 08:02 UTC
I read the following as array-based objects are 20% faster and 70% 40% smaller than the hash based equivalent for little extra effort and no loss of clarity. Depends on what you're doing. Even with this simple case I'd argue that having to maintain the array indices constants away from new() already make it slightly less clear. Once you have inheritance of array based objects it gets tricker since you have to keep the constants in sync between the parent and child classes. Remembering whether you've used array index 8 is a lot harder than remembering if you've used hash key something_the_parent_does. Once you start refactoring classes and moving object fields between classes, adding fields to classes, etc. I find array based objects becomes a complete PITA.	[reply]
Re^6: Which, if any, is faster? (20% faster/ 40% smaller) by BrowserUk (Patriarch) on Jun 02, 2005 at 08:22 UTC
I would not advocate this use for anything other than those applications that require the performance or memory gains or both. Example: Data::Trie & Tree::Trie. Both of these modules use hash-based instantiations. The problem is that they require so much room for each node in the trie that they are next to useless for any practical purpose. It's a simple case of using Perl to it's best advantage to achieve the desired goal. Blanket statements that all Perl OO modules should be hash-based completely ignores the possibilities of 3 or more other ways Perl's flexibility can be used to good affect to avoid having to drop into the nightmare of XS programming or the deep dependancies of Inline::C. Perl6 will provide the Perl programmer with a much greater degree of control over the storage representation of data elements and aggregates and it will (hopefully) impose far less penalties for using OO dispatching. Till then, if your application needs to deal with large volumes of concurrent, in-memory instances, or you want to extract the best performance from a given class, using the flexibility that Perl's OO mechanism provides to achieve your requirements is simple practical. Noone's advocating that every Perl class should be re-written to use an array-based representation to gain the 20%/40% benefits they can provide. If you don't need to optimise don't. If throwing hardware at the problem is an option; do so. It's just another option available to those that want or need it that can be safetly (and quietly) ignored by those that either don't need it or choose not to use for whatever reasons. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal? "Science is about questioning the status quo. Questioning authority". The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.	[reply]
Re^7: Which, if any, is faster? (20% faster/ 40% smaller) by adrianh (Chancellor) on Jun 02, 2005 at 15:39 UTC
I would not advocate this use for anything other than those applications that require the performance or memory gains or both. Didn't think you were :-) Blanket statements that all Perl OO modules should be hash-based completely ignores the possibilities of 3 or more other ways Perl's flexibility can be used to good affect to avoid having to drop into the nightmare of XS programming or the deep dependancies of Inline::C. Agree completely. The only issue I had was with "little extra effort and no loss of clarity" since I think array based objects end up involving quite a bit of extra work in many real world situations. The final working code can look quite clear - but getting there, and later maintenance, can be a complete bugger.	[reply]