Hi Barce For the CPU going wild, it would be best to share the code (if you can't share the whole project, then a relevant part of it that is runnable and exhibits the perf problem). There are many possible problems that could cause this, it is not self-evident that the use of sync.Map is the problem.
For the sync.Map documentation <https://golang.org/pkg/sync/#Map>, it basically says that this new Map type introduced in Go 1.9 is useful in some specific cases, but not very useful in other cases. The set of conditions for sync.Map to be useful and performant are (all must be true): - "concurrent loops" : you have multiple goroutines accessing the Map, each within its own loop ; - "keys that are stable over time" : e.g. strings are very stable, custom structs whose contents changes are not ; - "either few steady-state stores, or stores localized to one goroutine per key" : e.g. when distinct goroutines almost always write distinct entries (different keys). The part of doc that says "...than an ordinary map paired with a read-write mutex." means that in some cases, it is a better idea to use the built-in (non-concurrent-safe) map type, but to carefully lock a RWMutex <https://golang.org/pkg/sync/#RWMutex> before each access, which prevents data races. Cheers Val On Saturday, October 21, 2017 at 3:54:24 PM UTC+2, barce show wrote: > > how to understand this sentence > > For use cases that do not share these attributes, it will likely have > comparable or worse performance and worse type safety than an ordinary map > paired with a read-write mutex. > -- 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. For more options, visit https://groups.google.com/d/optout.
