I was looking at some old slides of Joe Armstrong on Concurrency-orinted programming. He set the following challenge: Put N processes in a ring: Send a simple message round the ring M times. Increase N until the system crashes. How long did it take to start the ring? How long did it take to send a message? When did it crash? He gave graphs comparing Erlang, Java and C#. I decided to compare Pharo. Here is what I got; the creation times are PER PROCESS and the messaging times are PER MESSAGE. first run procs creation/µs msg/µs 200 0 7.0 500 0 9.7 1000 2 15.4 2000 1 21.6 5000 13 31.5 10000 19.9 40.7 20000 46.5 55.4 50000 130.9 98.0 second run procs creation/µs msg/µs 200 0.0 7.0 500 0.0 10.12 1000 0.0 16.53 2000 1.5 24.26 5000 12.8 32.15 10000 28.1 39.497 20000 58.15 52.0295 50000 75.1 95.581 third run procs creation/µs msg/µs 200 0.0 7.0 500 0.0 8.6 1000 2.0 11.0 2000 1.0 16.55 5000 10.2 21.76 10000 12.0 49.57 20000 52.35 65.035 50000 91.76 117.1 Each process is a Pharo object (an instance of ERringElement) that contains a counter, a reference to the next ERringElement, and an "ErlangProcess" that is a Process that contains a reference to an instance of SharedQueue (its "mailbox"). The good news is that up to 50k processes, it didn't crash. But it did run with increasing sloth. I can imagine that the increasing process-creation time is due to beating on the memory manager. But why the increasing message-sending time as the number of processes increases? (Recall that exactly one process is runnable at any given time). I'm wondering if the scheduler is somehow getting overwhelmed by all of the non-runable processes that are blocked on Semaphores in SharedQueue. Any ideas? (My code is on Squeaksource in project Erlang. But be warned that there is a simulation of the Erlang "universal server" in there too. To run this code, look for class ErlangRingTest.)