I was running trio calling with hs38DH.fa and --threads option on recent develop branch head 3882f8f ... I noticed that the initial step of writing the headers for temporary .bcf files for each contig was taking a relatively large amount of time (a bit over a minute per contig, even for the small ones, which adds up with thousands of contigs).
It appears that the temporary caller initialization used to determine the CallTypeSet may involve a fair amount of overhead. For example, in some sampled stack traces (octopus.issue95.backtraces.txt), I noticed some operations involving ReadSetProfile DepthStats. I'm guessing a lot of this is not strictly needed for getting the CallTypeSet? If so, it seems like there may be an opportunity for streamlining the performance. I suppose another route might be to just get the call types once (rather than per contig)?
I was running trio calling with
hs38DH.fa
and--threads
option on recent develop branch head 3882f8f ... I noticed that the initial step of writing the headers for temporary .bcf files for each contig was taking a relatively large amount of time (a bit over a minute per contig, even for the small ones, which adds up with thousands of contigs).I traced the bottleneck to get_call_types: https://github.com/luntergroup/octopus/blob/be006425202073729d249e1a93349f596685d3b4/src/core/octopus.cpp#L132
It appears that the temporary caller initialization used to determine the CallTypeSet may involve a fair amount of overhead. For example, in some sampled stack traces (octopus.issue95.backtraces.txt), I noticed some operations involving ReadSetProfile DepthStats. I'm guessing a lot of this is not strictly needed for getting the CallTypeSet? If so, it seems like there may be an opportunity for streamlining the performance. I suppose another route might be to just get the call types once (rather than per contig)?