I'm wondering if using *sync.Map* wouldn't be the best option for performance reasons for this application, since it's a specialized map implementation. Does anyone know anything about this?
Em quarta-feira, 9 de outubro de 2024 às 15:27:09 UTC-3, robert engels escreveu: > The best way (imo) to perform the compaction is to use multiple sub maps - > i.e. partition the keys - and then you can compact these using RW locks to > limit the stop the world. > > On Oct 9, 2024, at 1:07 PM, Nico Braun <rainbo...@gmail.com> wrote: > > I started thinking about the compaction, and if there was a way to prevent > stopping the world during cleanup. May be interesting to look how etcd or > redis something does it. > > Could you use a RWMutex for this map, or is this not a good use case? > > On Wednesday 9 October 2024 at 08:36:34 UTC+2 Def Ceb wrote: > >> I've found this package to be useful for this in the past: >> https://github.com/jellydator/ttlcache >> >> On Wed, Oct 9, 2024, 04:31 Cleberson Pedreira Pauluci < >> pauluci....@gmail.com> wrote: >> >>> Hello. I found this very interesting. >>> >>> I have some questions: >>> >>> Have you considered the possibility of using *time.Duration* for the >>> *maxTTL* parameter? >>> Maybe wouldn't it be more interesting if each item had its own *maxTTL* >>> instead of just one for any item on the map? >>> >>> If you'll allow me, I made those adaptations to your original code. >>> Here's the example: https://go.dev/play/p/rba6HCJe-4X >>> >>> Thanks. >>> >>> >>> Em segunda-feira, 7 de outubro de 2024 às 16:37:53 UTC-3, Alex Pliutau >>> escreveu: >>> >>>> In some cases your application doesn’t need Redis, and internal >>>> in-memory map with locks and expiration will suffice. >>>> >>>> For example you already know the size of the map and you don’t need to >>>> store a lot of data. Use cases could be IP rate limiting, or any other >>>> short-lived data. >>>> >>>> Here is how you can implement this data structure in Go, let’s call it >>>> a TTLMap: >>>> >>>> https://gist.github.com/plutov/69d22552c696d48496563529c624e0b7 >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "golang-nuts" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to golang-nuts...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/golang-nuts/a59272be-7277-4cb6-a7a7-8bf4bdcefc40n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/golang-nuts/a59272be-7277-4cb6-a7a7-8bf4bdcefc40n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/924e3ebf-c2a6-4288-be14-8b187a46ab25n%40googlegroups.com > > <https://groups.google.com/d/msgid/golang-nuts/924e3ebf-c2a6-4288-be14-8b187a46ab25n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/fc43af25-566a-4e88-b1e3-ba97e226f351n%40googlegroups.com.
