Re: Up for Critique

Here's just something that came to mind. Instead of using your massive if structure in ParseAChroms, you could try doing something a lot simpler, such as declaring what you're looking for in a sort of table:

my %acrhom_prefix = (
    BAC         => '(.*)\s*',
    LENGTH      => '(.*)\s*',
    OSME        => '(.*)\s*',
    CHR_START   => '(.*)\s*',
    BAC_START   => '(.*)\s*',
    BAC_END     => '(.*)\s*',
    ORIENTATION => '(\w)\w*\s*',
);
[download]

Now, instead of using an "array" of variables, use a hash. This simplifies things massively:

sub ParseAChroms
{
     my ($achromref) = @_;
     my (%value);
     foreach (@$achromref)
     {
          my ($prefix, $data) = /^(\S+):\s+(.*)/;
          if (my $pattern = $achrom_prefix{$prefix})
          {
               ($value{lc $prefix}) = $data =~ /^$pattern$/;
          }
     }

     return @data{qw[ type ac_id length
                      chr_num chr_start chr_end
                      bac_start bac_end orient]};
}
[download]

Now, I've just typed this into the editor here, so this is really just theory and not tested, but the idea is that this can be applied to a few other areas where you do the same thing.

Further, instead of passing arguments back and forth in a particular fixed order, why not return a HASH-ref? This makes it easy to add new data to the return value without breaking other functions which use it.

Comment on Re: Up for Critique Select or Download Code

Replies are listed 'Best First'.
Re: Re: Up for Critique by biograd (Friar) on Mar 23, 2002 at 06:43 UTC
There were a couple reasons I went for the wholesome all-array approach...one of them is I have just never been as comfortable with hashes as I have been with arrays. This is no excuse, of course, and I've been meaning to use them more. I just always see the array algorithm first. (Can you tell I'm new???) Second, I'd read in Mastering Algorithms with Perl about the speed of arrays over hashes, so I felt justified. (Webadept noted this below too.) However, I can see the utility of hashes from many of these examples, yours and others below, so I know I'll have to bite this bullet soon. Thanks for the example, tested or not. :) -Jenn	[reply]
(jeffa) 3Re: Up for Critique by jeffa (Bishop) on Mar 23, 2002 at 17:31 UTC
Speed vs. Maintainability/Scalability If the difference in speed is small, i say drop the arrays and use hashes ... but i am lazy. I have this adversion to something called 'typing'. ;) But, arrays are not always faster than hashes. It all depends upon context - if you have to scan the entire array to find something, a hash implementation will probably be faster. But if you have to iterate over all elements - then an array is probably the better choice. Consider the following Benchmark code: use strict; use Benchmark; my %h; my @a = ('a'..'zzz'); @h{@a} = (1) x @a; timethese('-10', { find_array => sub { return (grep /^ccc$/, @a) ? 1 : 0 }, find_hash => sub { return $h{'ccc'} }, iterate_array => sub { do {} for @a }, iterate_hash => sub { do {} for keys %h }, }); __END__ yields on my dual proc 400 linux box: (YMWV) find_array: 10 wallclock secs (10.11usr + 0.04sys = 10.15 CPU) @ 45.62/s (n=463) find_hash: 13 wallclock secs (11.41usr + 0.07sys = 11.48 CPU) @ 1183591.72/s (n=1 +3587633) iterate_array: 11 wallclock secs (10.98usr + 0.09sys = 11.07 CPU) @ 70.28/s (n=778) iterate_hash: 11 wallclock secs (10.78usr + 0.05sys = 10.83 CPU) @ 16.53/s (n=179) [download] jeffa L-LL-L--L-LL-L--L-LL-L-- -R--R-RR-R--R-RR-R--R-RR B--B--B--B--B--B--B--B-- H---H---H---H---H---H--- (the triplet paradiddle with high-hat)	[reply] [d/l]