bam / boom timings

[Brent Pedersen]

Hi, I had seen the benchmark in the bam repo, but I wanted to check on
something that did attribute acess and made a new benchmark that gets
chrom, start, end, mapq 10 times for each element.

hts.bam is very fast even with many attribute accesses. In case anyone
is interested, here is the code:
https://gist.github.com/brentp/d40dfda347d07e601587
with the timings for hts.bam and biogo.boom in the comment below it.

-Brent

[Dan Kortschak]

Thanks for posting that Brent.

The reason we see that pattern is because of two things: 1) hts/bam is intended to be run multithreaded, so the single threaded instance unfortunately bears the cost of the machinary for that, but we see wins over boom when we do use more threads; and 2) boom has cgo call cost for attribute accesses though it does only does this for the first access to reduce the cost.

What I would like to see benchmarks for is a real-world-simulating random access pattern that exercises the implicit cache and also with a cache type set). I have not done this yet due to an absence of a need for my actual research work.

Dan

[Brent Pedersen]

Hi Dan,
in a real use-case (at least for me) I did see some slow down with
hts.bam with the Record.End() method -- I assume since it's parsing
the cigar string, but I cached the end and it's no longer an issue.
What remains high in the profile (other than malloc and garbage
collection stuff) are calls inside of flate and the ReadByte()

That use-case is streaming through the entire bam and accessing chrom,
start, end multiple times.