in reply to Re: how can I speed up this perl??
in thread how can I speed up this perl??

Your suggestion will save some, but just some. You've replaced the fetching of a value from walking 4 pointers to walking 2 pointers. That's a peephole optimization; the big gain is to be made by not comparing so much.

Even if you don't want to use a hash, you can still do:

if ($genome [$i] eq 'a') { if ($genome [$i + 1] eq 'a') {$aa ++} elsif ($genome [$i + 1] eq 'c') {$ac ++} elsif ($genome [$i + 1] eq 'g') {$ag ++} elsif ($genome [$i + 1] eq 't') {$at ++} } elsif ($genome [$i] eq 'c') { if ($genome [$i + 1] eq 'a') {$ca ++} elsif ($genome [$i + 1] eq 'c') {$cc ++} ... etc ...
which reduces the number of comparisons from max 20 to max 5.

Abigail

Replies are listed 'Best First'.
Re: Re: how can I speed up this perl??
by pg (Canon) on Nov 24, 2003 at 17:07 UTC

    Yep, obviously the comparison is also a part of the problem. As a matter of fact, both of our posts in this sub-thread shall only be understood as performance analysis, the actual implementation still shall go after hash, which has everything resolved in one shot.

      Going a bit offtopic, how does the internal hash lookup compare to the array solution he has now? It seems to me that internally, Perl will be doing nearly the same thing - comparing the given key to each of the keys in the hash.
        The beauty of a hash is that Perl doesn't need to compare the string to every key in the hash. It computes the hash for the string and looks in the bucket for that hash. In a well balanced hash, there should only be one key in that hash. The string needs to be compared against the key(s) in the bucket.

        The hash replaces multiple comparisons with a hash calculation and usually one comparison.