I feel that there should be a more efficient way

There is. Your current process is ~O(900,000*60,000) = 54 billion.

If you reverse the logic of your lookups, by reading the list file into a hash first; you can then read the fasta file line by line and lookup the headers in the hash, which results in an O( 900,000 ) process.

Try this (untested) version which should run close to 60,000 times faster:

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

die "usage: $0 <fasta> <list>\n" unless @ARGV == 2;

my %list;
open(LIST, $ARGV[1]) or die;
while (<LIST>) {
    next if /^#/;
    my ($header, $score) = split;
    $list{ $header } = $score;
}
close LIST;


open(FASTA, $ARGV[0]) or die;
my $fasta = new FAlite(\*FASTA);
while (my $entry = $fasta->nextEntry) {
    if( exists $list{ $entry->def } ) {
        print $entry->def;
        print $entry->seq;
    }
}

close FASTA;
__END__
[download]

Wow thanks, only takes a couple seconds to finish! I had attempted to do the same thing, but could never get it working, and wasn't sure if/how it would actually increase the speed. Thanks again

The "if/how" is this:

Your first solution had an outer loop that runs 900,000 times. Inside that outer loop, there's an inner loop that runs 60,000 times. 60k * 900k is 54 billion total iterations inside the inner loop.

The proposed solution created a hash of 60000 elements. Then your 900000 line file is read line by line. Inside of that loop that iterates 900000 times, there's a hash lookup, which is almost free. There are a total of 60000 iterations needed to build the hash, and 900000 iterations needed to test each line of the FASTA file. The amount of work being done is, therefore, 960000 iterations.

Think of loops inside of loops as doing n*m amount of work, whereas loops followed by loops (no nesting) do n+m amount of work. Anytime you have the choice of an algorithm where the order of growth is the mathematical product of two large numbers, or an algorithm where the growth rate is the mathematical sum of the same two numbers, your sense of economic utility should be telling you that the latter will scale up better.




Dave

Hi, out of curiosity, as I work with fasta files a bit, why not use the Bio::DB::Fasta module from BioPerl for indexed access to any number of fasta files. Your example is precisely what this module is for, unless you're exercising OO programming. I used your sample data for the code below, if interested.

update: Initially, creating the db may take a moment depending on size of input files, but it works pretty quick every time it's accessed after that.

#!/usr/bin/perl
use Modern::Perl '2011';
use autodie;
use Bio::DB::Fasta;

die "Usage: $0 <fastaFile> <queryFile>\n" unless my( $fastaFile, $quer
+yFile ) = @ARGV;

open my $fh, '<', $queryFile;
chomp( my @queries  = <$fh> );
close $fh;
# trim header
@queries = map{ local $_ = $_; s/^>(\S+)\s+\d+/$1/; $_ } @queries;

# create indexed database from fasta file
my $db = Bio::DB::Fasta->new( $fastaFile );

open my $fh2, '>', 'querySeqs.fa';
for my $query ( @queries ) {
    my $seqheader = $db->header( $query );
    my $seqdna = $db->seq( $seqheader );
    say {$fh2} ">$seqheader";
    print {$fh2} format_sequence( $seqdna, 60 );
}
close $fh2;


sub format_sequence {
    my($sequence, $length) = @_; # sequence and length of line 
    open my $string_fh, '>', \ my $string; # print sequence to string
    for( my $pos = 0; $pos < length( $sequence ); $pos += $length ) {
        print {$string_fh} substr( $sequence, $pos, $length ), "\n";
    }
    $string;
}


output in file querySeqs.fa

>Chr1.ID=PAC:19650373;Name=AT1G11900.1;pacid=19650373;longest=1;Parent
+=AT1G11900.len361.i1.1_111
GTATGAATTCCAAAAATCCAGAACCGTTTTCGTGATTCATGTTATGCTCTCGTTGTTGTT
TTCTGATTGTTACTGCTCAGCGAGTTTCTTCTATCAATGTTTGATTCGATGAAGATGCGA
AATTTCGAACCATTGCTGTTCTTCTGAGTTTGATCGTTTTTTAGTTTCGGGGCTTTCACG
CTTCAGCTAGTGTTTGATTACGAAGTTTTCTGATTAAATGTGTGAGTTTTTTTGTAGTCA
TCTCGAAAACTGAGAAATCCATTTTTATAGATTTACATTGTTCATAGTTATATGTGGAAG
TTGATGATTGATGGTGATTCTGCAAATTGATGATTTGGTTTTCTGTTTATTGGCATTGCA
G
>Chr1.ID=PAC:19657430;Name=AT1G76660.1;pacid=19657430;longest=1;Parent
+=AT1G76660.len490.i1.2_394
GTTTCTGTTTAATTCTCTCTATTTTCGTTTGATTTCGACTTCTTGAGCTTTTACTTCTCT
CTGTCTCAGTTCTAACTTCTTCAGATTTTAAAGCTTTCGTTTTTTTGGCAAGTTGTTTTT
TTTTCCTACTTAGATCTGACTACTCCGACTCTGTTCACACTAATGTTCGTTAGGGTTTAT
GTTGAATCTCTCCTTTGATCATTATGTTATTGTAAAAATCCCAGCTTTATGCTAAATCGA
GCTAGTGATTCTTGAGAATTGAACAAAAAAGTTTTACATTTTTCTGAATTGCCATTCAAT
TAGAAGAAGAAAAAATTCAACCTTTTACTGGTTATGATCTAGATTCGATGCGTGTAAGCT
ATAAGATCACCATTTCGTGCTTTAGATCCATAATCATTGATTCACTATATGGCAATTATC
TTCTTGCTTCACAGATCTCTTTTACACTTACATGTCAAGTGTCTGAGTGTGTGTGTGTGT
CCTTTTGCAG
>Chr1.ID=PAC:19652608;Name=AT1G31420.1;pacid=19652608;longest=1;Parent
+=AT1G31420.len415.i1.13_217
GTTCTTATAATTCTTACTAATTCTGTTTGCTTTTAAAGCTATAACCTTTGATATTGTTGG
AAAGAGTGGGGTTTTGGGTCTTTTGCTGAATCGTTTTTTGGATTTGTTATATTGTTCGAA
TCTTCAGTTGTTATTGTGTTATAGGATTGGATGGTATCTGGGAATTTCGTAATCTATGTT
AAGCTAGAGCTGTTTTTGAGCTCTTTTGTTGATGATGATTTTGAGATTGTTGGCCGAATT
TAGCTCTCGTTTTCTGATTTTAGCAATTGGAAAGTGTGTATTGGTTCTTGTGAGGCAATT
TCACTGTTTTGAGTACTCAAAATGTAGATGAGAGCATGCATAAGTTGTGTGGAGACTGAG
CTTAATGTGTAGTGTAATTGACAATTAGTTTTGTGGGCTTTCCTTTGTTTTTCAG
[download]

Without prejudicing the OPs response in any way, can I ask you, what you think using Bio::DB::Fasta would have over the OPs 50 line module?

Given that to get it, he would have to try and install it and its 897 codependants -- not to mention AnyDBM_File and at least one of DB_File GDBM_File NDBM_File SDBM_File; all of which are a known problem on my platform -- and somehow resolve the 95 "cannot resolve"s (whatever they are?):

<Reveal this spoiler or all in this thread>

all to install an indexing module that he doesn't need, and won't benefit from, in order to complete his task in "a couple seconds".

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Without prejudicing the OPs response in any way, can I ask you, what you think using Bio::DB::Fasta would have over the OPs 50 line module?

Not having a CS background, I cannot analyze an algorithm for efficiency. However, Bio::DB::Fasta is an exisiting and, among biologists, widely used solution to a common task, presented by the OP. So, like you, I exercise the privilege to offer my solution.

Given that to get it, he would have to try and install it and its 897 codependants -- not to mention AnyDBM_File and at least one of DB_File GDBM_File NDBM_File SDBM_File; all of which are a known problem on my platform -- and somehow resolve the 95 "cannot resolve"s (whatever they are?):

So far, I've installed BioPerl on Ubuntu, RedHat, and Mac OS X without problems. If the OP happens to be in a biomedical field, it may be worthwhile to install and use BioPerl as it does solve many genomic tasks.

all to install an indexing module that he doesn't need, and won't benefit from, in order to complete his task in "a couple seconds".

"Without prejudicing the OPs response in any way"

It will help if you are looking to retrieve a subsequence from the human genome, the FASTA file of which is about 5 Gb; in the case of parsing a smaller FASTA file with just a few entries, it makes less of a difference.

Bioinformatics