A second question is that I am planning to run this script on a file that contain 10-15 million lines. Do you think this is the best way of doing it.

Code updated.

Maybe not. All your keys are numeric and chrM is only around 16k in length, so you can save space by using an array instead of a hash and the save time by not having to sort:

use warnings;
use strict;
use 5.010;

my @pos;

while(<DATA>){
    my( $chr, $start, $end ) = split;
    $pos[ $_ ]++ for $start .. $end;
}

for my $pos ( 0 .. $#pos ) ){
    next unless defined $pos[ $pos ];
    say $pos,"\t", $pos[ $pos ];
}
[download]

However, this might exhuast your memory if you tried to run in on some of the larger genomes.

Perl's documentation for sort provides the following example:

    # sort numerically ascending
    @articles = sort {$a <=> $b} @files;
[download]

So applying that to your code, it would look like this:

Perl's sort defaults to sorting ASCII-betically. If you want it to sort numerically, you need to supply a code block that uses the <=> operator (perlop).

Update:

Your second question is a good one. One area where you could improve would be to use an array instead of a hash as an accumulator. Although both array and hash lookups are O(1), the constant factor involved in hash lookups is more expensive than for array lookups. Since you're doing lookups 40 to 50 times per line from the file, and since all of your indices seem to be within a narrow numeric range from zero to fifty, an array makes a lot of sense. This would also eliminate the need to sort.

However, it's possible you're IO bound anyway, and that the time spent in calculating hash lookups is shadowed by waiting for input. ....profiling would tell a lot.

Thank you guys!