Poor performance when reading gzipped FASTQ sequentially about pyfastx HOT 6 CLOSED

Thank you for your posting. Pyfastx aims to enable random access to reads from FASTQ files which depends on an index file. If index file does not exists, pyfastx will build an index file when the FASTQ file is first opened. This step may consume much more time. When you open file again and read sequences, it will be very fast to iterate sequences and comparable to iteration without index. For gzipped file, in addition to positional index, it also will build seek point index for accelerating gzip seek operation.

from pyfastx.

Thanks for the quick reply.

When nothing is done with the reads except adding them to a list, pyfastx performs as expected. However, when the read attributes are accessed while processing the file (e.g. to filter based on quality) performance is very poor.

In my testing, the uncompressed file took 1m 5s wall time to build the index and process the full file, but the gzip-compressed version reliably failed to complete in less than an hour. This seemed to be the case whether or not a new index was built.

from pyfastx.

Thank you for reporting this hidden performance problem!
For iteration of reads from gzipped FASTQ file, each read was read by seeking to the start position and then read content using zran_read in zran.c. However, zran_read has a low performance for IO intensive operation which I didn't notice before. In later version, I will add a buffer reader to improve the performance. Thanks again!

from pyfastx.

No problem! Let me know when this is implemented and I'll happily update the examples in my package documentation.

from pyfastx.

We have improved the speed of reading sequence from gzipped FASTQ file in new version 0.6.10

from pyfastx.

@lmdu Just wanted to let you know that I've re-run the benchmarks for my package as part of a new release and pyfastx performance is greatly improved!

from pyfastx.