Question: SCOTCH computational performance

[lianov]

Hi all,

Great work here, but I have a question - do you all have any information about SCOTCH's computational performance (in particular time and memory) for processing long-read single-cell data?

I looked through the data you have presented thus far in the pre-print and how it compares to IsoQuant, but a performance benchmark would be extremely beneficial. Ideally it would also be good to have information on performance if one processes one BAM at a time or multiple BAMs as well.

Depending on this metric, I would be happy to add SCOTCH to our nf-core/scnanoseq workflow in the future. But before doing so, it would be great to know how it performs. Any information would be helpful.

Thanks!

[kaichop]

we will get back with a benchmark on computational performance under different scenario.

…

On Thu, Mar 5, 2026 at 7:06 PM Lara Ianov ***@***.***> wrote: *lianov* created an issue (WGLab/SCOTCH#10) <#10> Hi all, Great work here, but I have a question - do you all have any information about SCOTCH's computational performance (in particular time and memory) for processing long-read single-cell data? I looked through the data you have presented thus far in the pre-print and how it compares to IsoQuant, but a performance benchmark would be extremely beneficial. Ideally it would also be good to have information on performance if one processes one BAM at a time or multiple BAMs as well. Depending on this metric, I would be happy to add SCOTCH to our nf-core/scnanoseq workflow in the future. But before doing so, it would be great to know how it performs. Any information would be helpful. Thanks! — Reply to this email directly, view it on GitHub <#10>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABNG3OBEVIMRWPTH6GTTEMD4PIJABAVCNFSM6AAAAACWI4MLYGVHI2DSMVQWIX3LMV43ASLTON2WKOZUGAZTCMZWGE2DKOI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[zihian]

Would be interested to look at the performance!

Currently multiple BAMs seems to be processed sequentially (correct me if I'm wrong), I'm using NF to split the BAMs analysis to run in parallel, would be good to see it implemented natively.

I've also noticed in the compatible stage ('Processing groups for multiple reads...') in compatible.py line 165 results in a memory spike for a large dataset. Exposing the n_jobs to be defined by user at line 166 might be an option to solve this. Currently, I am trying to reduce memory by reducing total available CPUs.

Thank you for the hard work!

[Karenxzr]

benchmark_report.pdf

Hi @lianov , please find the pdf file for computational time benchmark with IsoQuant. Please let me know if you have any questions. Thank you!

[Karenxzr]

@zihian thanks for raising up the mem spike issue. i have updated codes to address it. currently compatible step consume much less mem than before.

[lianov]

@Karenxzr : thank you so much for the detailed report. As a last detail, could you share the version of IsoQuant which you benchmarked SCOTCH against?

[Karenxzr]

@Karenxzr : thank you so much for the detailed report. As a last detail, could you share the version of IsoQuant which you benchmarked SCOTCH against?

It is version 3.6