Konstantin Riege

Thank you for the reply. I can confirm the peak performance using 32 threads on our EPYC, too. In the meantime I was investigating this issue further. I compiled htslib...

Thank you for figuring this out! Does your pull request, which increases the blocksize to 1MB, affect the binary/legacy mode only?

To e.g. get just the second line of a file, I do something like `echo -e "foo\nbar\nzar" | gzip -c | tee foo.gz | gztool -v 0 -f -i -x...

> However, I am working on a compressed and sparse [index format](https://github.com/mxmlnkn/indexed_bzip2/blob/fbec01816f386810f392b7ebef9506acc5a0e8e1/src/rapidgzip/IndexFileFormat.hpp#L223) and this feature request is in time to add line information as a consideration to the file. Sounds...

> Are you doing `rapidgzip -d -c -P 8 | pigz` and `rapidgzip -d -c -P 8 | bgzip`? exactly. I am on an AMD EPYC 7513 with an NVMe...

Wow, you made it - this is super cool.. fast decompression with an offset! As far as I can tell you, I didn't observe any issues so far. But I'd...

followup: index creation from stdin does not work anymore. rapidgzip now complains `All window sizes must be at least 32 KiB or empty!`

> Ah, did I mention that the sparseness is also used for the gztool indexes? No, you didn't :) but I already wondered how you achieved gztool index size reduction.....

I am sorry to bother you again with stdin related issues. Using v0.14.1 index export works with "indexed_gzip" and "gztool" keywords, but fails on "gztool-with-lines" giving me the error ```...

> gztool already should give all the benefits I see. So except for index file size and the use case with `--count` option, there are no other drawbacks when switching...