Trinity runtime performance stats

[Brian Haas]

Greetings all,

Thanks to our colleagues at Indiana University (and special thanks to Ben Fulton, in particular), we are now capturing runtime and reconstruction performance stats across the various Trinity releases.

Results are available here:

http://trinityrnaseq.github.io/performance/

which are based on a few data sets that we routinely benchmark Trinity with (mouse, drosophila, and S. pombe).

--

--
Brian J. Haas
The Broad Institute
http://broadinstitute.org/~bhaas

 

[Will Holtz]

Any idea why the S. pombe run time got a lot shorter with v2.0.3 while the other two assemblies run times got a little longer?

-Will

--
You received this message because you are subscribed to the Google Groups "trinityrnaseq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to trinityrnaseq-u...@googlegroups.com.
To post to this group, send email to trinityrn...@googlegroups.com.
Visit this group at http://groups.google.com/group/trinityrnaseq-users.
For more options, visit https://groups.google.com/d/optout.

--

The information contained in this e-mail message or any attachment(s) may be confidential and/or privileged and is intended for use only by the individual(s) to whom this message is addressed.  If you are not the intended recipient, any dissemination, distribution, copying, or use is strictly prohibited.  If you receive this e-mail message in error, please e-mail the sender at who...@lygos.com and destroy this message and remove the transmission from all computer directories (including e-mail servers).

Please consider the environment before printing this email.

[Brian Haas]

Ben can probably tell us for sure, but I think it's because the of 

a.  the jaccard clipping step needed for S. pombe (compact genomes in general) now happens during the massively parallel phase instead of during the earlier serial phase from the earlier version (pre-2) of Trinity.

b.  the others are slightly slower because they don't use the jaccard clip and the massively parallel step has increased in complexity.  Note, it's not a whole lot slower, just slightly slower.  Also, note if we put this on a compute farm for the parallel stage, it would be ultra-fast in comparison.  (Ben - something to consider).

best,

~b

[Ben Fulton]

That's right. That last number is enough of a change that it might be worth rechecking, though, to make sure that the comparison is fair. I'll look into that.