On Mon, Sep 18, 2000 at 11:01:12AM -0700, Glenn Linderman wrote:
> One of the big complaints about today's perl objects is their slowness at
> accessing member data, which is a direct result of hashes being used as the
> base data type for the underlying member data items.
The speed differences between hashes and arrays are not the problem.
C<$val = $array[$idx]> and C<$val = $hash{$key}> both cost the same.
Beyond that, hashes start to lose, but not by much.
The real problem is the overhead of accessor method calls. This by
far swamps any little fluctuation between hash and array access.
Hopefully RFC 163 will fix this.
This is my typical benchmark:
#!/usr/bin/perl -w
use Benchmark;
%hash = (key => "foo");
$key = 'key';
$low_idx = 0;
@array = ('foo');
$hobj = bless {};
$aobj = bless [];
sub a_accessor {
$_[0]->[1];
}
sub h_accessor {
$_[0]->{key}
}
timethese(shift || 2_000_000,
{
control => sub { },
hash_lookup_var => sub { $hash{$key} },
hash_lookup_const => sub { $hash{key} },
hash_set_var => sub { $hash{$key} = 'foo' },
hash_set_const => sub { $hash{key} = 'foo' },
array_lookup_var => sub { $array[$low_idx] },
array_lookup_const => sub { $array[0] },
array_set_var => sub { $array[$low_idx] = 'foo' },
array_set_const => sub { $array[0] = 'foo' },
hash_accessor => sub { $hobj->h_accessor },
array_accessor => sub { $aobj->a_accessor },
}
);
Benchmark: timing 900000 iterations of array_accessor, array_lookup_const,
array_lookup_var, array_set_const, array_set_var, control, hash_accessor,
hash_lookup_const, hash_lookup_var, hash_set_const, hash_set_var...
array_accessor: 8 wallclock secs ( 7.94 usr + 0.00 sys = 7.94 CPU)
array_lookup_const: 2 wallclock secs ( 2.40 usr + 0.00 sys = 2.40 CPU)
array_lookup_var: 3 wallclock secs ( 2.96 usr + 0.01 sys = 2.97 CPU)
array_set_const: 3 wallclock secs ( 2.87 usr + 0.00 sys = 2.87 CPU)
array_set_var: 3 wallclock secs ( 3.50 usr + 0.00 sys = 3.50 CPU)
control: 2 wallclock secs ( 2.27 usr + 0.00 sys = 2.27 CPU)
hash_accessor: 8 wallclock secs ( 7.89 usr + 0.01 sys = 7.90 CPU)
hash_lookup_const: 3 wallclock secs ( 2.90 usr + 0.00 sys = 2.90 CPU)
hash_lookup_var: 3 wallclock secs ( 2.93 usr + 0.00 sys = 2.93 CPU)
hash_set_const: 3 wallclock secs ( 3.96 usr + 0.00 sys = 3.96 CPU)
hash_set_var: 4 wallclock secs ( 4.03 usr + 0.01 sys = 4.04 CPU)
Once the cost of benchmarking overhead is subtracted (ie, the 2.27
control) you can see that the accessors (~5.6 CPU) swamp the cost of
array or hash access (~0.6 to 1.6) and that there's little difference
between the array_accessor and the hash_accessor (the fact that the
hash accessor turns out a smidge faster places it well within
"experimental error")
BTW I ran this on 5.005_03 since I don't have a copy of 5.6 handy
without debugging flags. Could someone else run it and post the
results?
> The syntax
>
> $foo['element']
>
> would be interpreted as a reference to @foo. If the namespace for @foo
> contains 'element', that member of @foo is the interpretation. If the
> namespace for @foo does not contain 'element', then 'element' is added to the
> namespace for @foo, the size of @foo is increased by 1, and the member
> 'element' refers to the newly added item in @foo.
I know, lets call it a pseudo-hash!
Been there, done that, worn the scars proudly.
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
Sometimes these hairstyles are exaggerated beyond the laws of physics
- Unknown narrator speaking about Anime
