Optimize data structures used by librasan

[WorksButNotTested]

Description

Replace BTreeMap and BTreeSet with hashbrown data types.

Checklist

• I have run ./scripts/precommit.sh and addressed all comments

[domenukk]

We should do this, eventually :D
#3218

XXH3 is fast but more optimized for files IIRC, not for small ahash-like problems

[domenukk]

we have a cargo bench for them

[WorksButNotTested]

@wfdewith FYI.

[wfdewith]

One question: my understanding is that ahash is very fast because it exploits hardware acceleration for AES instructions. Does QEMU emulate this, especially cross-architecture? Since we're only hashing GuestAddr which are always 32 or 64 bits integers and we don't need DoS resistance for those either, I would assume without any testing that fxhash is faster than ahash for these purposes.

[WorksButNotTested]

One question: my understanding is that ahash is very fast because it exploits hardware acceleration for AES instructions. Does QEMU emulate this, especially cross-architecture? Since we're only hashing GuestAddr which are always 32 or 64 bits integers and we don't need DoS resistance for those either, I would assume without any testing that fxhash is faster than ahash for these purposes.

You know more than me. I just went with it because it said it was fairly quick. TBH, I think the majority of the performance improvement comes from moving from BTree based storage to hash based. Happy to take a PR to change the algo if you prefer?

[wfdewith]

I'll try to spend some time this weekend to write a benchmark under QEMU, which will give us some hard numbers to compare.

[WorksButNotTested]

@wfdewith Cool, sounds good. Care to join the discord? Might be easier than communicating through issues in future?
https://discord.gg/gCraWct