search

ruanjue / wtdbg2

Redbean: A fuzzy Bruijn graph approach to long noisy reads assembly
GNU General Public License v3.0
513 stars 94 forks source link

slower runtime in v2.3 #68

Closed evanrrees closed 5 years ago

evanrrees commented 5 years ago

Hi,

I have noticed substantially slower runtimes with wtdbg2.3 compared with 2.1 on the same dataset. I'm using 100 Gbp of ONT reads on a ~3 Gbp heterozygous plant genome (diploid size 6 Gbp).

With v2.1:

wtdbg2 -i ont.fq -o prefix -t 108 -L 10000 -k 15 -p 0 -S 2 -F --minimal-output
** PROC_STAT(TOTAL) **: real 24563.741 sec, user 2331182.950 sec, sys 85556.430 sec, maxrss 190960304.0 kB, maxvsize 226690392.0 kB

wtpoa-cns -t 54 -i prefix.ctg.lay -o prefix.ctg.fa
** PROC_STAT(TOTAL) **: real 13405.858 sec, user 279609.340 sec, sys 5456.390 sec, maxrss 4455744.0 kB, maxvsize 6289948.0 kB

and v2.3:

wtdbg2 -i ont.fq.gz -o prefix -t 108 -L 10000 -k 17 -p 0 -S 4.0 --minimal-output
** PROC_STAT(TOTAL) **: real 112461.779 sec, user 1922185.270 sec, sys 201843.300 sec, maxrss 288261880.0 kB, maxvsize 570885184.0 kB

wtpoa-cns -t 108 -i prefix.ctg.lay.gz -fo prefix.ctg.fa
** PROC_STAT(TOTAL) **: real 46509.592 sec, user 883821.400 sec, sys 64671.380 sec, maxrss 10685316.0 kB, maxvsize 14965120.0 kB

So with v2.1, wtdbg2 and wtpoa-cns take ~7 hrs and ~4 hrs respectively, while in v2.3 they take ~31 hrs and ~13 hrs. One major difference I can see is that the alignments and ctg.lay outputs are compressed - could this be contributing to the slowdown?

Thanks!

ruanjue commented 5 years ago

Thanks for the report. I saw the sys time increased very large, not sure whether it was caused by system or new code. I also found v2.3 run slower than v2.1 on huge dataset, but not too much. Anyway, I will test this problem.

Best, Jue

evanrrees commented 5 years ago

Thanks for looking into this. These were run on two different servers with the following specs, though I believe the only difference is greater RAM in the second run. v2.1: four 14-core (28-hyperthreaded) Intel Xeon E7 4850 v3 14C 2.1-2.8GHz, 12TB SATA HD (RAID10), 1TB SSD HD, 512GB RAM v2.3: four 14-core (28-hyperthreaded) Intel Xeon E7 4850 v3 14C 2.1-2.8GHz, 12TB SATA HD (RAID10), 1TB SSD HD, 1024GB RAM

ruanjue commented 5 years ago

Recently, I got a similar case. It was caused by every read have many alignments, processing the alignments block other threads. Now, I fix it at https://github.com/ruanjue/wtdbg2/tree/gcov , please have a try with it.

ruanjue commented 5 years ago

Now, branch gcov is merged into master, please checkout https://github.com/ruanjue/wtdbg2/commit/8908a3162362df842e540658a45222f764e629a7. It should answer your question.