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.

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?

> 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.

> 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.

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

> Memcache uses an outdated and slow hash and hashtable.

No it doesn't. A cursory scan through the code will tell you as much.

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.

Not this again...

https://news.ycombinator.com/item?id=28833202