You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
). 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>>(...);
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?
The text was updated successfully, but these errors were encountered: