Use xxh64 to hash the s-mer in syncmers #313
Conversation
|
Awesome, approved! |
|
While measuring memory usage for #314, I also got numbers for how much memory increases due to this PR (XXH64). Here are the numbers for completeness. Change in memory usage (MB)
It’s not that much, but I feel a little bit bad because we’re again eating up some of the memory savings from #278. It’ll be a bit weird in the changelog: "We reduced memory usage from 23 GiB to 13 GiB, but then made other changes and it’s now back at 14.7 GiB" ... |
|
I don't feel bad about it :) PR #278 allows us to (i) change to 64-bit pointers (which robin hood couldn't do) which explains part of the re-increase. |
|
I only wrote "a little bit bad" ... 😄 No I think it’s fine. Answering here regarding b tipping over: No, it’s 28 in both cases. It appears to be just the size of the |
|
Ah makes sense! If we are out for saving memory we could always experiment with density (e.g., k-s = 6 instead of 4) but I think it's fine as is. The mapping rate would go down for the shortest reads with more thinning. |
Use xxh64 to hash the s-mer in syncmers
Single-end accuracy