-
Notifications
You must be signed in to change notification settings - Fork 14
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
Comments
Actually this might be a RAM/speed tradeoff - if we lazy load gene/PRGs into RAM only when we see them? |
(Hope i'm not misrepresenting you @Danderson123 , I can delete this or update it) |
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 |
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 |
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.
The text was updated successfully, but these errors were encountered: