When looking at the performance aspects of the OP's code, I'd like to point out a few things about the "if" statement that you may not be aware of:

if (  $sUnpackedCDPcap ne $sPhoneCapabilityCode 
    & $sUnpackedCDPcap ne $s3905CapabilityCode )
{
  ##Do some stuff##
}
[download]

Please refer to Perl Operators for more details.
The "ne" is a string operator, not a numeric one. A numeric compare of two integer binary values is something that the CPU can do very,very quickly in a single ALU (Arithmetic and Logic Unit) operation. String comparisons are byte by byte comparisons. With your 8 character strings, it could be that eight ALU operations are required to establish string equality instead of just a single operation for a binary number. Also when comparing strings there is some loop overhead so we don't "run off the end", etc. Summary: comparing a binary number is much faster than comparing a string.

Also look at the "&" operator. This is a bit-wise operation that "and's" two things together. Both sides of the "&" are evaluated then and'ed together.

Binary "&&" performs a short-circuit, C-style logical AND operation. That is, if the left operand is false, the right operand is not even evaluated. This is different than the single '&' bitwise operator.

In Perl numeric values start out as strings. The numeric representation of a string is not calculated unless that needs to happen. I think there are some Monks who understand Perl Guts well enough to explain what this "if" statement will do. I believe that the numeric values of these variables will be calculated and used in the evaluation of the "if". If another "if" clause is added, it will run much faster because say, $sPhoneCapabilityCode will already exist as a numeric value, not a string.

if ( ($sUnpackedCDPcap != $sPhoneCapabilityCode) &&
     ($sUnpackedCDPcap != $s3905CapabilityCode ) )
{
  ##Do some stuff##
}
[download]

I am very skeptical that a hash approach can beat a simple numeric "if" approach for small n, say <10. Byte by byte string operations like calculating the numeric hash key of a string are just inherently slower than a single operation that compares 2 numeric values together.

I haven't done any bench marking, but I think the logic of my argument is compelling enough to warrant more investigation.

Update: Adding some benchmark code to show difference between string and numeric "if" versions:

#!usr/bin/perl
use strict;
use warnings;

use Benchmark qw(:all);

my $count = 100000000; # one hundred million cycles

my $sUnpackedCDPcap = "00000491";
my $sPhoneCapabilityCode = "00000490"; 
my $s3905CapabilityCode   ="00000290";

timethese
($count, 
        {
       'String_if' =>  \&string_if,
       'Do_Nothing' => \&do_nothing,
       'Numeric_if' => \&numeric_if,
        }
);

sub do_nothing
{
   #don't do anything
   return;
}

sub string_if
{
       
    #$sUnpackedCDPcap is Dynamically generated during the program
    
    if ($sUnpackedCDPcap ne $sPhoneCapabilityCode & 
        $sUnpackedCDPcap ne $s3905CapabilityCode )
    {
      ##Do some stuff##
    }
    return;
}

sub numeric_if
{
    if ( ( $sUnpackedCDPcap != $sPhoneCapabilityCode) && 
         ( $sUnpackedCDPcap != $s3905CapabilityCode ) )
    {
          ##Do some stuff##
    }
    return;
}

__END__
Benchmark: timing 100000000 iterations of Do_Nothing, Numeric_if, Stri
+ng_if...
Do_Nothing:  4 wallclock secs ( 4.03 usr +  0.00 sys =  4.03 CPU) @ 24
+801587.30/s (n=100000000)
Numeric_if: 15 wallclock secs (16.44 usr +  0.00 sys = 16.44 CPU) @ 60
+83835.25/s (n=100000000)
String_if: 25 wallclock secs (26.59 usr +  0.00 sys = 26.59 CPU) @ 376
+0388.07/s (n=100000000)
[download]

The difference between "do nothing" and the other benchmarks is so small that I wouldn't worry much about it. If you are going to do this 10 times, nobody will care! If you are doing this 100 million times, then yes, somebody will care. Note that I added a "do_nothing" test case. This measures some of the overhead in the test harness and I find adding a test case like that to be useful to "set a bottom execution floor" that can be achieved. An explicit return in all subs normalized the return values to be the same amoungst subroutines.

At the end of the day, we are comparing things which are very similar. I did not benchmark the hash solution... left to the reader. I just wanted to make the point that numeric vs string comparisons are faster.