vg giraffe extremely slow on Illumina PE data unless rescue is disabled (-A none): clarification on trade-offs

[Sumit1331]

Hello vg team,

Thank you for developing and maintaining vg and giraffe.

I observed that vg giraffe can be extremely slow on Illumina paired-end WGS data mapped to a minigraph-cactus pangenome graph on an HPC system. Some samples (fungal pathogen) took more than a day to finish with default settings, even after trying common solutions such as colocating inputs and outputs, copying index files (including .dist) to local scratch etc. In contrast, when I disabled rescue using -A none, the same samples completed in minutes and produced .gam files consistently.

After disabling rescue, the .gam file looks like:

This suggests that rescue is the dominant performance bottleneck in my case. I would appreciate clarification on the trade-offs of disabling rescue, particularly regarding sensitivity loss and whether -A none is generally acceptable for high-coverage Illumina WGS and downstream SNP or population-genetic analyses.

Or do you have any other suggestions on how to speed up the process?

Thank you very much for your time and guidance.

Best regards,
Sumit

[jltsiren]

The underlying cause is probably graph complexity. If large indels are common, the region where the pair could plausibly be (according to distances in the graph) can be large, and rescue attempts take a lot of time.

Instead of disabling rescue completely, you could try adjusting the parameters:

• --rescue-attempts INT: attempt up to INT rescues per read in a pair (default: 15)
• --rescue-subgraph-size FLOAT: search for rescued alignments within FLOAT standard deviations of the expected location (default: 4.0)
• --rescue-seed-limit INT: attempt rescue when there are at most INT minimizer seeds in the region (default: 100)

Building a less complex graph would be a better option, but we don't know how to do that reliably.

I don't know if anyone has investigated the effects of rescue on variant calling performance.