xqrs takes hours on about 5% of ECG traces; minutes for the other 95%

Function xqrs seems highly inconsistent on runtime from one ECG trace to another and I am not sure how to predict if a trace can be processed in minutes or many hours. The split is about 95% of traces are processed fast (minutes) and about 5% take hours. Some of quickly processed traces have more heartbeats or are across a longer clock time so it is not directly tied to trace length or trace clocktime duration. Processing seems to be either quick (minutes) or very slow (hours) - it is bimodal, not a continuous range. Trace durations I am working with are from under an hour to 24 hours. The longer traces are more likely to take hours with xqrs, but as stated I have even longer traces that take minutes. These are 1-channel traces. How do you suggest avoiding the slowdowns?

If I breakpoint the xqrs code, it seems the slowdown may be related to the _run_detection code (which is called by xqrs) sometimes doing backsearch. It would be helpful to know more about what backsearch is doing, when it is triggered, and how far back it rescans. Clearly if it rescans a large percentage of the earlier marked signal, then it will cause a quadratic slowdown as it gets further into a trace. I think this type of slowdown is what I am seeing when I breakpoint. How far back does it rescan and if far back, why? If far back, what would be the downside in me limiting the scope of the backsearch to a much shorter period? Is it possible that if the code makes bad decisions on the first few heartbeats used during learning that this can throw off the later backsearch, causing this hours-long execution?

Perhaps related, I see that the default wfdb_conf.t_inspect_period = 0.0 in the latest version was recently changed from a default wfdb_conf.t_inspect_period = 0.36. The value of 0.36 seems like it might be correlated to some traces taking much longer, but it is possible I am in error on this. I find the 0.36 value does a much better job of avoiding falsely marking t-waves as a qrs so it is highly desireable to keep using 0.36 rather than 0.0.

The documentation on wfdb_conf.t_inspect_period is very terse. It says "The period below which a potential QRS complex is inspected to see if it is a T-wave. Leave as 0 for no T-wave inspection." Is the 'period' a time window after the location of a qrs complex where the code avoids finding another qrs complex? Is the period 's units seconds? How does the default wfdb_conf.t_inspect_period affect the backtrace?

This set of issues may also be related to this issue: https://github.com/MIT-LCP/wfdb-python/issues/180

I can arrange to get you ECG traces that run fast and slow on xqrs if that is helpful, but would prefer to not publicly post them. Thanks.

Start with xqrs and its _run_detection path, then inspect how backsearch and wfdb_conf.t_inspect_period are handled. Compare the reported fast and slow traces, and review issue #180; done means documenting the slowdown trigger and behavior, explaining the t_inspect_period setting, and identifying a safe way to avoid the hours-long runtime.