Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve performance of deep decoding of BAM files. #77

Merged
merged 3 commits into from
May 18, 2017

Conversation

alumi
Copy link
Member

@alumi alumi commented May 16, 2017

This PR adds some performance optimization for reading BAM files.

  • Use defrecord for alignment instead of map
  • Avoid multimethod
  • Parse options in lazy-seq
  • Avoid char in case
  • Compute :end while decoding cigar code and cache them
  • Read little-endian values directly from ByteBuffer.

Sequential reading will get 50~60% faster when :options are not referred and 30~40% faster with :options.

@codecov
Copy link

codecov bot commented May 16, 2017

Codecov Report

Merging #77 into master will decrease coverage by 0.28%.
The diff coverage is 79.88%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master      #77      +/-   ##
==========================================
- Coverage   83.04%   82.76%   -0.29%     
==========================================
  Files          59       59              
  Lines        3833     3840       +7     
  Branches      409      422      +13     
==========================================
- Hits         3183     3178       -5     
+ Misses        241      240       -1     
- Partials      409      422      +13
Impacted Files Coverage Δ
src/cljam/io.clj 100% <100%> (ø) ⬆️
src/cljam/lsb.clj 95.77% <100%> (+11.15%) ⬆️
src/cljam/bam/reader.clj 84.84% <100%> (ø) ⬆️
src/cljam/bam/decoder.clj 65.95% <42.1%> (-17.26%) ⬇️
src/cljam/util/sam_util.clj 87.08% <83.33%> (-1.04%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 35126e9...0298a6f. Read the comment docs.

@alumi alumi self-assigned this May 16, 2017
@alumi alumi force-pushed the feature/faster-bam-deep-reader branch from 90f12a1 to 7ec9d15 Compare May 17, 2017 04:43
@alumi alumi requested a review from totakke May 17, 2017 06:08
@alumi alumi assigned totakke and unassigned alumi May 17, 2017
Copy link
Member

@totakke totakke left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good performance, but some revisions are required. Please check comments.

PS. I tested performance of direct linking before. As a result, there were no significant difference in speed and size (size slightly reduced). So I didn't enable it. Of course, enabling it does not matter.

[(.toString sb) ref-length]))))

(defrecord SAMAlignment [^String qname ^int flag ^String rname ^int pos ^int end ^int mapq ^String cigar
^String rnext ^int pnext ^int tlen ^String seq ^String qual options])
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cljam.bam.reader/read-alignments returns SAMAlignments, but cljam.sam.reader/read-alignments still returns maps. Both read-alignments should return SAMAlignment consistently. Other defrecord location should be considered.

Additionally, type hints of record fields seem to have no effect in this case.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed cljam.sam.reader/read-alignments to return SAMAlignments.
SAMAlignment is now defined in cljam.io without ^String type hints.

[refs id]
(if (<= 0 id (dec (count refs)))
[refs ^long id]
(when (<= 0 id (dec (count refs)))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why using when? when should be used for multi forms or forms including side effects. I think if is better.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer when because one can tell at a glance that the function may return nil.

In clojure.core.clj, ifs without third arg are less than 1% of entire use of if, while when with single body is commonly used.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I personally think existence of side effects is more important than whether the function return nil. The third argument of if is not a serious matter. Well, OK in this case because style guide about if/when hasn't been established yet.

l-read-name
n-cigar-op
l-seq))
pos (inc (.getInt buffer))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These changes about buffer reading reduces readability and component merit. I think enhancing each lsb/read-*** function with protocol is better. If so, performance of cljam.bcf.reader will improve as well.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I replaced lsb/read-*** functions with a protocol and extensions.

@alumi
Copy link
Member Author

alumi commented May 18, 2017

Thank you for the reviewing!
I've added some more commits to resolve problems.

I confirmed that effects on the performance by these changes are limited.

@totakke totakke merged commit 979b434 into master May 18, 2017
@totakke
Copy link
Member

totakke commented May 18, 2017

Thank you for fixes :)

@alumi alumi deleted the feature/faster-bam-deep-reader branch May 18, 2017 10:55
@alumi
Copy link
Member Author

alumi commented May 18, 2017

Thank you so much!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants