> Is this really the case? AFAIK arc/orc doesn't do any locking but I haven't > been keeping up with it much. Any further reading on how this locking > operates?
when you create a ref object with gc:arc/gc:orc it calls [nimNewObj](https://github.com/nim-lang/Nim/blob/80a0dc295bab6d7699c0da13b6bc90f7243572e4/lib/system/arc.nim#L86) which in turn calls [alignedAlloc0](https://github.com/nim-lang/Nim/blob/2bda4a30a6b12dd0840dc347e454e54fe26721e7/lib/system/memalloc.nim#L354) which when the program is compiled with threads:on calls allocShared0, which in the end when Nim's integrated allocator is used, is [implemented](https://github.com/nim-lang/Nim/blob/cfdac6666f5772479724e082fb08c2db694d8d40/lib/system/alloc.nim#L1102) via a lock and unlock of a mutex. I've profiled the tree benchmark and locking and unlocking was the number one measured hotspot. All [Nim benchmarks](https://github.com/hanabi1224/Programming-Language-Benchmarks/blob/main/bench/bench_nim.yaml) on that site are compiled with threads:on and gc:orc, iirc some of the Nim benchmark made use of parallism.
