Profiling results

[kevlar-dev]

Profiling results

[standage]

Perhaps. I'd need to create a consume_string_banding function, but probably want to do this anyway,

That said, based on my most recent discussion with Fereydoun, we're probably going to settle for discarding reads with non-ACGT. This represents a small portion of data, and if any of our variant calls are coming only from these potentially problematic reads then that's a cause for skepticism anyway. And if I understand correctly, the Cython-based read pre-processing is moving in this direction anyway, so this should make our life much easier!

[betatim]

Can you do your preprocessing on a per read basis or is it per kmer? Wondering if you could speed things along by passing a read to consume_string instead of calling add for each kmer. It might reduce the (notoriously large) function call overhead of python and maybe we make some gains by having the loop in c++?