faster min_node_support when support is 0

[glennhickey]

Changelog Entry

To be copied to the draft changelog by merger:

• vg call patched so that certain problem cases no longer take forever.

Description

I'm not sure if there's a github issue for this, but I think it comes from here:
https://www.biostars.org/p/9572558/

and @jeizenga was kind enough to pass over the data, with which it is easy to reproduce.

But I still don't really understand what's going on. Usually it boils down to one big snarl, but in this case it just seems to be going a bit slow on every single snarl. And whenever I pause it, it's always inside PackedTraversalSupportFinder::get_min_node_support()

I don't know why this function would cause a slowdown on this particular graph, and I suspect there's something going on that I should be figuring out but am not.

The good news is that there's a fairly obvious speedup: quit computing the min() if 0 is ever found. And... somehow that seems to be enough to get it to run through on this input.

[jeizenga]

This Biostars question, actually: https://www.biostars.org/p/9572558/

[jeizenga]

A thought I just had: someone pointed in this comment that this is a very repetitive genome stemming from LTR transposon activity. Maybe it could have something to do with that?