I should have said that my evaluation is just self-written cycle measurement, which is very rough and lack of repeated experiment. So the factor number might be different in your case. But the contention for the single sync.Mutex really hinders the performance in my case.
> "what evidence is there a thread-local cache would?" Strictly speaking, I'm not looking for thread-local, but P-local (similar to per-cpu data in linux). Since a P can contain only one goroutine at any time, the P-local storage needs not locking. Only when I flush the batched items into the global lru cache, the exclusive locking is needed. Now that P-local storage does not exist, Im thinking about reducing the operations on the list. Not every operation needs to delete-and-reinsert element from the list, but just changes some attributes of the item itself. That is a compromise of LRU strategy, but in this way, we only need read lock if we operate on the item itself instead of the list. I am not an expert in caching and golang, so please correct me if I misunderstand anything. Jesper Louis Andersen <jesper.louis.ander...@gmail.com> 于2019年7月24日周三 下午10:44写道： > On Wed, Jul 24, 2019 at 7:16 AM Zihan Yang <whois.zihan.y...@gmail.com> > wrote: > >> >> I tried to evaluate the performance with lru & without lru, the >> performance with a global lru is 10x slower than without lru at all. >> >> > This would make me step back a bit and revisit my initial plan. If a > global cache isn't helping, what evidence is there a thread-local cache > would? Said another way, the work you are caching must have a certain > computational overhead to it, which warrants a cache in the first place. > > -- 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/CAKwiv-i0_q02bL2VNRovR231sVNOWqJdz_SeuEcjNoirYrq9sQ%40mail.gmail.com.
