I was playing with measuring Actor performance

As of topic of actors performance, there was a thread replicating Go’s channels and out of curiosity I’ve made actors implementation to compare performances: Async Channels for Swift concurrency - #44 by vns

In general actors are quite good from performance perspective: there are cases where strategically put locks might perform better, especially if locks allow significantly reduce number of hops between executors (you can see in the thread that syncRw version is the slowest in either implementation exactly because there are a lot of hops back and forth), but for a majority of use cases they are pretty performant on their own.

So that if you have small chunks of work between which you expect to switch extensively, I’d prefer lock over actor — in that case you have zero hops between executors.

Also, I want to highlight the fact that your code with locks here is completely synchronous, while actors version is by nature introduce some asynchronous work. I think to be completely fair in comparison, you would need to introduce offloading to a separate queue for lock version and probably introduce some level of parallelism — so that your code is actually being mutated from different threads (for both locks and actors versions).

2 Likes