Does btree.Map use concurrency locks?

[benduckwdesign]

Just a general question, noticed NewMap does not have the option to turn locks on or off like btree.New does.

[tidwall]

That’s correct. Map does not have built in locks.

[benduckwdesign]

I had a database lock wrapper implementation for standard Go maps which was about 600ns/op for random in-memory reads, but using btree.Map seemed to have worse performance over the standard implementation in my test scenario which is why I thought maybe I was putting locks over locks.

Since then I have moved over to using a custom implementation of sync.Map (thus removing my lock wrapper, down to 400ns/op random in-memory reads,) but I'm not sure if the techniques used (one dirty store, one read-only store) would be efficient or applicable for btree structure in order to create a potentially faster "btree.SyncMap". Not asking for an implementation, nor am I committing to contributing one, but it's a curious idea.

In any case, thanks for this library and the quick support.