Re^5: Hash versus chain of elsifs

Some feedback on your posted code:

Always post a SSCCE
Your hash is not correct (which would have been picked up with a SSCCE).
Always Use strict and warnings
Don't use $a or $b as your variable name because they have special meanings in Perl.
DRY (you have repeated $a unnecessarily in your sample code).

Anyway, here is a very simple example of how I would go about it.

use strict;
use warnings;

# Using block lexical scope to data-hide %junksites
{
    my %junksites = (
        'bollyinside.com' => 1,
        'www.bollyinside.com' => 1,
        'worldtrademarkreview.com' => 1,
        'www.worldtrademarkreview.com' => 1,
    );

    sub KnownJunkSite {
        my $val = shift;
        return exists $junksites{$val};
    }
}

for my $v ('bollyinside.com', 'fred', 'www.worldtrademarkreview.com') 
+{
    print "$v: ", KnownJunkSite($v) ? "found\n" : "not found\n";
}
[download]

Running this little test program produces:

bollyinside.com: found
fred: not found
www.worldtrademarkreview.com: found
[download]

Update: Should you write a Procedural Module or an OO Module or just use a Hash?

In your case, if I wrote a module, I'd use OO. See also:

Re: Procedural vs OOP modules (this is how I decide: OO or Procedural?)
High Performance Game of Life (package Organism in "Perl Solution" section is a simple example of a Perl OO module based on a hash)

... though I'd also consider not writing a module at all, instead just using a hash/hashref directly, as analysed below in my reply to this reply.

Comment on Re^5: Hash versus chain of elsifs Select or Download Code

Replies are listed 'Best First'.

Re^6: Hash versus chain of elsifs
by eyepopslikeamosquito (Archbishop) on Nov 23, 2021 at 11:34 UTC

If performance is an issue, you might consider eliminating the lookup function call overhead (and the arguments about whether your module should use state or our or lexically scoped my ;-) simply by not writing a function at all! Instead performing your hash lookups directly.

To test this idea, I wrote the following little benchmark:

use strict;
use warnings;
use Benchmark qw(timethese);

# Test hash
my %junksites = (
   'bollyinside.com' => 1,
   'www.bollyinside.com' => 1,
   'worldtrademarkreview.com' => 1,
   'www.worldtrademarkreview.com' => 1,
);

sub KnownJunkSite {
   my $val = shift;
   return $junksites{$val};
}

my @testlist = ( 'bollyinside.com', 'www.bollyinside.com', 'fred', 'ww
+w.worldtrademarkreview.com' ) x 1000;

sub fn_lookup {
   for my $v (@testlist) {
      my $t = KnownJunkSite($v);
   }
}

sub hash_lookup {
   for my $v (@testlist) {
      my $t = $junksites{$v};
   }
}

my $href = \%junksites;

sub hashref_lookup {
   for my $v (@testlist) {
      my $t = $href->{$v};
   }
}

timethese 50_000, {
   Fn      => sub { fn_lookup()      },
   Hash    => sub { hash_lookup()    },
   HashRef => sub { hashref_lookup() },
};
[download]

Running the little benchmark program above on my laptop displayed:

Benchmark: timing 50000 iterations of Fn, Hash, HashRef...
       Fn: 28 wallclock secs (27.56 usr +  0.00 sys = 27.56 CPU) @ 181
+4.03/s
     Hash: 11 wallclock secs (11.62 usr +  0.00 sys = 11.62 CPU) @ 430
+1.08/s
  HashRef: 12 wallclock secs (12.02 usr +  0.00 sys = 12.02 CPU) @ 416
+1.12/s
[download]

Note that in the sample code above, to make a direct hash lookup more pleasing to the eye, I eliminated the call to exists simply by ensuring all keys have the true value 1.

No surprise that using the hash directly is a lot faster than calling a function every time you do a lookup. Also of interest is that a hash lookup is only marginally faster than a hash_ref lookup.

Based on this benchmark, rather than agonizing over whether your function should use block lexical scope or the Perl 5.10 state feature or an our variable, you might instead choose not to use a function at all! That is, perform the lookup directly via a hash, rather than a function call. Note that using a hashref, rather than a hash, gives you the flexibility to call your code with many different hashes, at a miniscule performance cost.

[reply]
[d/l]
[select]


No such thing as a small change
	PerlMonks