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
Implement it on my own in the downstream project I will use.
Implement it as totally new crate (one that would take any hashmap?)
Implement it on the counter crate
Implement it here.
For 1, outside of trivial usage I feel that there is value for this to exists independently in a crate form whether part of an existing one or a new one. That leads to 2. I think it is obvious that building a collection that extends hashmap while being fast AND concurrent is non trivial.
I have not yet engaged in specific discussions with the developer of the counter crate, but considering how it is a small and simple crate with 2k LoC including docs, I feel that it might be overcomplicating it.
I am still investigating performance opportunities there but it seems I might have underestimated the task.
The brings me to trying to implement it here.
From a brief reading of the code from both, I feel like there is a path to way to cleanly implement it, and I am willing to do the legwork and prepare an initial PR.
My question would be if there is interest in merging it at all?
I have a feeling that there is an unmet and uncommunicated need for this kind of collection.
Although I have limited knowledge into their operations, crates.io for instance, might be able to capitalize on this kind of collection instead of accessing DashMap's low level apis.
Anyway, I will repeat that I am willing to put in the effort necessary to develop, discuss, and debug such a feature if there is interest.
The text was updated successfully, but these errors were encountered:
Just to avoid any confusion, I will likely not be able to singlehandedly implement the whole thing alone.
Esp considering that I am not yet versed in the rust approach to concurrent code. I will give a best effort though.
I am interested in multiset collections such as Python's
Counter
or Rust'sCounter
.I see a few possible pathways
counter
crateFor 1, outside of trivial usage I feel that there is value for this to exists independently in a crate form whether part of an existing one or a new one. That leads to 2. I think it is obvious that building a collection that extends hashmap while being fast AND concurrent is non trivial.
I have not yet engaged in specific discussions with the developer of the
counter
crate, but considering how it is a small and simple crate with 2k LoC including docs, I feel that it might be overcomplicating it.I am still investigating performance opportunities there but it seems I might have underestimated the task.
The brings me to trying to implement it here.
From a brief reading of the code from both, I feel like there is a path to way to cleanly implement it, and I am willing to do the legwork and prepare an initial PR.
My question would be if there is interest in merging it at all?
I have a feeling that there is an unmet and uncommunicated need for this kind of collection.
Although I have limited knowledge into their operations,
crates.io
for instance, might be able to capitalize on this kind of collection instead of accessing DashMap's low level apis.Anyway, I will repeat that I am willing to put in the effort necessary to develop, discuss, and debug such a feature if there is interest.
The text was updated successfully, but these errors were encountered: