Show HN: A simple zero-dependency in-memory key-value store for Golang

Posted by tomaszsobota on Wednesday August 17, 2022 @09:45AM
from the show-hn dept.

There are plenty of other caches and KV stores out there, but this one aims to minimise the surface a bit more: - There's less error handling required due to some code simplifications made - It stores only strings so no type-casting is required - There are no mutexes involved so we're not locking writes at any point

This is one of my first OSS contributions so I'd love some feedback :)

( 4 comments | 3 points | on HN )

Re:Show HN: A simple zero-dependency in-memory key-value sto... by geoah on Wednesday August 17, 2022 @09:49AM (#32496336)

Have you benchmarked this against using a sync.Map based version by any chance? It would be really interesting to see what’s the performance difference.

[ Parent | on HN ]

Re:Show HN: A simple zero-dependency in-memory key-value sto... by tomaszsobota on Wednesday August 17, 2022 @10:00AM (#32496505)

That's a great idea, I'll try and do that! Also, thanks for dawning on me the existence of `sync.Map`, I tried looking for something native but somehow I missed this. I guess tbkv won't match the native code performance, but it's a great exercise nonetheless! :)

[ Parent | on HN ]

Re:Show HN: A simple zero-dependency in-memory key-value sto... by tomaszsobota on Wednesday August 17, 2022 @06:34PM (#32502609)

The difference is even more than I expected.

On my hardware, a simple Set->Get scenario takes TBKV 1500 ns/op where sync.Map takes only ~80 ns/op to perform the same task.

That's a 20x difference in duration :(

The benchmark code is already in master.

[ Parent | on HN ]

Re:Show HN: A simple zero-dependency in-memory key-value sto... by Ajnasz on Wednesday August 17, 2022 @11:53AM (#32497978)

I like the idea of using channels.

Maybe it would be good to be able to pass a context for the store, so the loop stops when the context cancelled.

[ Parent | on HN ]