Re: [go-nuts] Map with expiration

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 wrote: > > I started thinking about the compaction, and if there was a way to

Re: [go-nuts] Map with expiration

My project github.com/robaho/go-concurrency-test may be of interest in evaluating this. The timings are old, but AFAIK the analysis still holds. > On Oct 9, 2024, at 2:05 PM, Cleberson Pedreira Pauluci > wrote: > > I'm wondering if using sync.Map

Re: [go-nuts] Re: Map with expiration

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 C

Re: [go-nuts] Map with expiration

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)

Re: [go-nuts] Using structs, pointers, and maps

I agree with what Axel said in the below: ```a lot of people *do* take it as a pretty hard rule. Not as hard as a compilation error or a vet failure, but still in a way that they think it is generally agreed that it should never be done. ``` The way I read the https://go.dev/wiki/CodeReviewCom

Re: [go-nuts] Using structs, pointers, and maps

So can I say that, if I'm not writing concurrency code, it's acceptable for me to mix pointer and value receiver? I find that like what @Axel said, I think there's some struct in STD Lib doing this too? case in point, Time struct in "time" package. On Tuesday 8 October 2024 at 10:29:09 pm UTC+8

Re: [go-nuts] Using structs, pointers, and maps

On Tuesday 8 October 2024 at 07:37:25 UTC+1 Axel Wagner wrote: the only one on the "mixing receiver kinds is sometimes necessary, so we shouldn't caution against it" side of the table To me this sounds like a false dichotomy. It can be good general good-practice advice to avoid mixing pointer

Re: [go-nuts] Using structs, pointers, and maps

On Wed, 9 Oct 2024 at 09:54, Ken Lee wrote: > So can I say that, if I'm not writing concurrency code, it's acceptable > for me to mix pointer and value receiver? > Note that you can't really know, if your users use concurrency or not. And I still maintain, that concurrency is - mostly - a red he

Re: [go-nuts] Is "When in doubt, use a pointer receiver" misleading advice?

Hi Oliver is the link already available? Would like to learn more about this On Tuesday 14 November 2023 at 7:23:44 am UTC+8 Oliver Lowe wrote: > > I'd be curious to hear thoughts on this topic. > > There was a fun talk at GopherConAU just a few days ago: "What's > The Point? A Guide To Using Poin

Re: [go-nuts] Using structs, pointers, and maps

On Wed, 9 Oct 2024 at 10:42, 'Brian Candler' via golang-nuts < golang-nuts@googlegroups.com> wrote: > On Tuesday 8 October 2024 at 07:37:25 UTC+1 Axel Wagner wrote: > > the only one on the "mixing receiver kinds is sometimes necessary, so we > shouldn't caution against it" side of the table > > >

Re: [go-nuts] good practice or premature optimization

On Wed, Oct 9, 2024 at 8:51 PM Nico Braun wrote: > > Hi, recently I became very self aware of potential performance implications > my code might have. > > In go there are a few key concepts, like escape analysis and bound checks. If > you check the standard library, you can see it was coded with

[go-nuts] Why isn't the memory model part of the spec?

It seems required to understand how Go programs work. If the memory model was never written, or is omitted from an implementation, would the concurrency features still be reliable and useful? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To u

[go-nuts] good practice or premature optimization

Hi, recently I became very self aware of potential performance implications my code might have. In go there are a few key concepts, like escape analysis and bound checks. If you check the standard library, you can see it was coded with micro optimizations. For example, disabling bound checks