Regarding 'small but predictable cost'... that's not entirely true. In an earlier life I worked on an object-oriented operating system based around reference c

Regarding 'small but predictable cost'... that's not entirely true. In an earlier life I worked on an object-oriented operating system based around reference counting, called intent (you won't have heard of it), and it was horrible. One of the major issues with refcounting is that when you dereference an object, it may be freed then and there... which dereferences any dependent objects... which may be freed... which dereference more objects, etc. So any time you dereference your object, you may end up doing an arbitrary amount of work, which isn't good for real-time performance. You can usually avoid this by being sensible about when you reference and dereference objects, but now you're effectively doing manual memory management, which slightly defeats the whole point of the exercise. In our case, we also cocked things up with poor design --- we ended up reffing and dereffing objects a lot, which meant we constantly ran into issues where we needed to deref an object with a lock held, which isn't a good idea. A better designed system wouldn't have done this. Objective C's memory pools work very well: whenever you create an object it gets added to a list, and all objects on the list are dereffed when your app exits to the event loop; so not only do you only need to manually ref objects if you want to keep them until the next event, which is much easier to code for, but the object free overhead all happens at a well-defined point which is usually app idle time. So while reference counting can help, it still doesn't make the problem go away, and when you're using it you have to remember that you are using it and ensure that your app is designed to cope. (It's also worth remembering that modern incremental garbage collectors solve the same problem in a different way, and without some of refcounting's problems.)