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

.clear() taking too long #162

Open
abhimanyu891998 opened this issue Jun 14, 2024 · 1 comment
Open

.clear() taking too long #162

abhimanyu891998 opened this issue Jun 14, 2024 · 1 comment

Comments

@abhimanyu891998
Copy link

Hey @manugoyal , when calling .clear() on cuckoohash_map, it takes about 1-2 ms. Is this expected? And is there a faster way to reset the hash map?

@manugoyal
Copy link
Contributor

Hi @abhimanyu891998. Off the top of my head, I would guess clear takes a while because it must take all the table locks (

auto all_locks_manager = lock_all(normal_mode());
). This is necessary because clearing cannot race with other concurrent operations on the table which may be reading/writing data.

It would be useful to benchmark what part of clear is taking a long time for you. If you are running clear at a point where no concurrent operations are running on the table, I would think that acquiring all the uncontended locks should be pretty fast, and clear shouldn't take much time. In which case, there might be other reasons.

If you are trying to clear while concurrent operations are occurring, the fastest approach might be to replace the table with a freshly-allocated one. Which could be safely managed with shared pointers or something. For example:

auto my_table = std::make_shared<cuckoohash_map<int, int>>(...);
// Do stuff
...
// Quickly "clear" the table by replacing it with a fresh one. Existing concurrent operations will continue
// to operate on the old table.
my_table = std::make_shared<cuckoohash_map<int, int>>(...);

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