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

Benchmarks #3

Open
hoytech opened this issue Sep 29, 2020 · 0 comments
Open

Benchmarks #3

hoytech opened this issue Sep 29, 2020 · 0 comments

Comments

@hoytech
Copy link
Owner

hoytech commented Sep 29, 2020

Out of curiosity I hacked up part of the liburkel benchmark to work with Quadrable.

Inserting 100k records took about 3 times longer with quadrable compared to liburkel. Same with the get. The commit was basically identical (probably since both are basically just an msync).

I'm pretty satisfied with this result. liburkel's backing data-store is more specialised compared to ours which is just vanilla LMDB. If we feel like racing in the future here are some things we could try:

  • In the liburkel benchmark the hashing of keys is done once up-front, whereas in Quadrable we are hashing keys again on insertion. We could extend the API to support pre-hashing like in liburkel, which would make the benchmark more equivalent.
  • We could use a faster hash function. Right now it's an unoptimized keccak256 function for ethereum compatibility. liburkel uses blake2b which is way faster.
  • Reduce dynamic memory allocation and pointer chasing during bulk insertion. There are probably better containers than std::map for this, for example a flatmap of some sort.
  • Segregate leaf nodes into their own table to improve locality?
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

1 participant