performance issues with accessing bgzipped ancestral fastas

[wsdewitt]

Accessing later regions of a fasta via a mutyper.Ancestor object (child class of pyfaidx.Fasta) is not performant, likely stemming from this issue in pyfaidx: mdshw5/pyfaidx#153.

This is particularly problematic for the mutyper targets subcommand, since it scans through all sites in a fasta record, or a sequence of bed regions.

The current workaround is to work with decompressed fasta data. A bgzipped fasta, e.g. named ancestor.fa.gz can be decompressed with bgzip -d ancestor.fa.gz to produce an uncompressed fasta ancestor.fa.

[wsdewitt]

This continues to cause problems, so suggest raising a warning with a link to this issue if a .gz file is supplied.

[ab08028]

I ran into this issue using mutyper variants, good to know there's a workaround! Thanks to Luke for helping me troubleshoot!

[ab08028]

Running into this again with a new dataset, and it's wild the difference in performance this makes. Ran the job with the bgzipped fasta for >2 days and only got 400MB through a vcf file, and now with the unzipped fasta am already at 1.5GB after an hour. Maybe consider throwing a warning or error if someone tries to input a compressed ancestral fasta? it's virtually unusable when it's that slow

[mdshw5]

I just want to chime in and say that I've fixed the performance of pyfaidx indexed retrieval of bgzipped FASTA files in mdshw5/pyfaidx#164. The code passes my existing test suite and I plan on doing a bit more testing before releasing a new stable version. If this is still an issue for your project I'd be grateful for any feedback, and sorry @ab08028 for wasting a few days of your time with my previous approach!