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

Pandora mapping is slow #347

Open
iqbal-lab opened this issue Oct 18, 2023 · 4 comments
Open

Pandora mapping is slow #347

iqbal-lab opened this issue Oct 18, 2023 · 4 comments

Comments

@iqbal-lab
Copy link
Collaborator

iqbal-lab commented Oct 18, 2023

Placeholder as @Danderson123 keeps saying this and I don't want to lose it. Mapping reads from one sample to a
PRG (Ecoli + a few thousand AMR genes) taking 30 mins with 64 cores. I realise our performance stats in the pandora paper are
a) way out of date
b) end to end performance of doing pandora compare on 20 samples.
I don;t think mapping can ever be as fast as the subsequent steps @Danderson123 does with amira, so it's not realistic to expect that, but I do want to understand if this is true (and set my expectations on how fast mapping is), or something weird about Dan's setup.

@iqbal-lab
Copy link
Collaborator Author

Actually this might be a RAM/speed tradeoff - if we lazy load gene/PRGs into RAM only when we see them?

@iqbal-lab
Copy link
Collaborator Author

(Hope i'm not misrepresenting you @Danderson123 , I can delete this or update it)

@Danderson123
Copy link
Collaborator

This is correct, I will try to make plots of runtime vs number of reads after I have looked at the gene calling in more detail- without lazy loading the RAM usage was far higher than is reasonable for a laptop

@iqbal-lab
Copy link
Collaborator Author

I have to say @Danderson123 , first mapping to an AMR-only PRG and only keeping those reads, and then mapping just those to the big PRG, would probably make a significant difference

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

No branches or pull requests

2 participants