>
> | 05/19/10
Did some performance tests on my local aligner implementations. Using my latest commit (5aff5ddf561ee005fb96fa01082479a53364d475), over 1,000 randomly generated sequence pairs of length 500:
| Aligner |
Avg Time (s) |
Total Time (s) |
| Normal Local Aligner |
0.01465 |
14.65 |
| Banded Local Aligner |
0.0009 |
0.9 |
| Normal Vectorized Local |
0.00389 |
3.89 |
| Banded Vectorized Local |
0.00029 |
0.29 |
Note these were not done on a Release build because the Release build messes up the vectorized banded aligner for some reason (outputs all 0). I'll have to look into why building as "Release" build is wrong but a regular build is not. I think it might be going wrong in my "custom" signed max function.
I also started profiling the baligner, after making sure all the output was correct. Since aligning the 125000 reads Daniel usually uses would have been way too slow, I used the e_coli_1000_1.fq reads file as a test. I ran memcheck first and fixed all the memory leaks that arose. I also ran callgrind over baligner and I found a significant bottleneck in the gap aligner, where a constant 256*256 matrix was being initialized and reinitialized multiple times over all the reads, when it only needed to be initialized once. After the fix, the speed increase was significant:
| Test |
Time (s) |
| Before fix, 1,000 reads |
20.26 |
| Before fix, 125,000 reads |
401.71 |
| After fix, 1,000 reads |
2.72 |
| After fix, 125,000 reads |
71.98 |
For tomorrow:
- Find out why the vectorized banded local aligner isn't working on a Release build and fix it.
- Benchmark the local aligner using Release builds.
- Do more profiling of the baligner.
|
Copyright © 2008-2025 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.