4 ms·

This seems to be a concurrent hashmap (dashmap[1]) with a server speaking the memcached protocol. I know both memcached and redis use sophisticated strategies t

This seems to be a concurrent hashmap (dashmap[1]) with a server speaking the memcached protocol. I know both memcached and redis use sophisticated strategies to reduce allocation calls and memory fragmentation, but this seems to do nothing like that. [1]: https://docs.rs/dashmap/latest/dashmap/ https://docs.rs/dashmap/latest/dashmap/

CodesInChaos 5y ago
> use sophisticated strategies to reduce allocation calls and memory fragmentation Both of these are things a high quality allocator (jemalloc in this case) has to to optimize for as well (in this context "allocation calls" corresponds to syscalls). For example they also allocate different sizes from different buckets. Applications do have some abilities an allocator does not have, for example: * It can move allocations, since it can invalidate pointers. This allows defragmentation/compaction to happen * It can try to predict how long lived an allocation will be But it's not clear to me if any of these are important for performance.
rurban 5y ago
Memcache uses an outdated and slow hash and hashtable. This is using jemalloc and a concurrent hashtable. Seems to be miles better.
- Lhiw 5y ago
  Not this again... https://news.ycombinator.com/item?id=28833202 https://news.ycombinator.com/item?id=28833202
- tinktank 5y ago
  > Memcache uses an outdated and slow hash and hashtable. No it doesn't. A cursory scan through the code will tell you as much.
  - rurban 5y ago
    Exactly why I told so. I even started to improve it some years ago, but got sidetracked. The only nice thing about the code are signals on htable updates. But a proper, fast concurrent hashtable would work wonders.
saulrh 5y ago
Honestly, still kind of impressive that an off-the-shelf concurrent hashmap can get within even a factor of two of the best-in-class hundreds-of-engineer-years piece of open-source software and all the fine-tuning that major enterprise users have contributed to it. Like, given how much infra budget goes into running big KV stores, I'd assume that memcached has been optimized to within an inch of its life across almost the entirety of its codebase, all the way up to the really hardcore stuff. Being able to just... grab a package and get within spitting distance of it is kind of amazing. IME when you do that you're lucky to get within two OOM.
- AceJohnny2 5y ago
  I agree, but on the other hand you know the saying: "90% of the work takes 90% of the time, the 10% remaining takes the other 90% of the time." How much effort would be required to get memc to equal or surpass memcached's performance? Would it require rewriting the datastructures from scratch? Fine-tuning or rewriting the tokio?
- Aperocky 5y ago
  > factor of two of the best-in-class Would be surprised if it didn't, and most of the time it should probably be even. It's the edge cases that separates naive implementation from industrial usage. And off the shelf concurrent hashmaps are already pretty advanced.

CodesInChaos 5y ago

> use sophisticated strategies to reduce allocation calls and memory fragmentation Both of these are things a high quality allocator (jemalloc in this case) has to to optimize for as well (in this context "allocation calls" corresponds to syscalls). For example they also allocate different sizes from different buckets. Applications do have some abilities an allocator does not have, for example: * It can move allocations, since it can invalidate pointers. This allows defragmentation/compaction to happen * It can try to predict how long lived an allocation will be But it's not clear to me if any of these are important for performance.

rurban 5y ago

Memcache uses an outdated and slow hash and hashtable. This is using jemalloc and a concurrent hashtable. Seems to be miles better.

Lhiw 5y ago
Not this again... https://news.ycombinator.com/item?id=28833202 https://news.ycombinator.com/item?id=28833202
tinktank 5y ago
> Memcache uses an outdated and slow hash and hashtable. No it doesn't. A cursory scan through the code will tell you as much.
- rurban 5y ago
  Exactly why I told so. I even started to improve it some years ago, but got sidetracked. The only nice thing about the code are signals on htable updates. But a proper, fast concurrent hashtable would work wonders.

saulrh 5y ago

Honestly, still kind of impressive that an off-the-shelf concurrent hashmap can get within even a factor of two of the best-in-class hundreds-of-engineer-years piece of open-source software and all the fine-tuning that major enterprise users have contributed to it. Like, given how much infra budget goes into running big KV stores, I'd assume that memcached has been optimized to within an inch of its life across almost the entirety of its codebase, all the way up to the really hardcore stuff. Being able to just... grab a package and get within spitting distance of it is kind of amazing. IME when you do that you're lucky to get within two OOM.

AceJohnny2 5y ago
I agree, but on the other hand you know the saying: "90% of the work takes 90% of the time, the 10% remaining takes the other 90% of the time." How much effort would be required to get memc to equal or surpass memcached's performance? Would it require rewriting the datastructures from scratch? Fine-tuning or rewriting the tokio?
Aperocky 5y ago
> factor of two of the best-in-class Would be surprised if it didn't, and most of the time it should probably be even. It's the edge cases that separates naive implementation from industrial usage. And off the shelf concurrent hashmaps are already pretty advanced.