Re: [Samtools-help] Picard SamToFastq performance

[Alec W. <al...@br...>]

Hi Sean,

We don't get a lot of complaints of SamToFastq being slow.  One theory: 
when outputting paired reads, SamToFastq stores the end with lower 
coordinate in an in-memory hash map until it encounters the other end.  
In general this map should not get very large, because the second end is 
usually encountered not too long after the first end.  However, if your 
reads are unusual, e.g. jumping library or other situation in which the 
ends are far apart, the map might get large and things might get 
slower.  Increasing the amount of RAM you give the JVM (using -Xmx 
argument) might help.

If that doesn't help, try generating a few thread dumps while the 
program is running.  You do this with 'kill -QUIT <pid>'.  This will 
write a thread dump to stderr.  Send those along and I'll take a look.

-Alec

On 5/27/11 6:58 AM, Sean Davis wrote:
> Hi, all.
>
> I am running on a BAM file that is the result of aligning a set of
> 80bp paired-end reads.  It is coordinate-sorted.  SamToFastq.jar has
> been running for several hours and is making very slow progress (on
> the order of 30 MB/hour).  Is this expected?
>
> Thanks,
> Sean
>
> ------------------------------------------------------------------------------
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery,
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now.
> http://p.sf.net/sfu/quest-d2dcopy1
> _______________________________________________
> Samtools-help mailing list
> Sam...@li...
> https://lists.sourceforge.net/lists/listinfo/samtools-help