On Fri, 18 Apr 2014 10:00:21 -0400, Ola Fosheim Grøstad
<ola.fosheim.grostad+dl...@gmail.com> wrote:
On Friday, 18 April 2014 at 12:55:59 UTC, Steven Schveighoffer wrote:
The important thing to recognize is that it's the *caller* that
increments/decrements. This means you can elide calls to an object
where you already have a guarantee of its reference count being high
enough.
That won't help you if you iterate over an array, so you need a mutex on
the array in order to prevent inc/dec for every single object you
inspect.
If the array is shared, and the elements are references, yes. It's also
possible that each object uses a reference to the array, in which case the
array could be altered inside the method, requiring an inc/dec even for
unshared arrays.
inc/dec with a lock prefix could easily cost you 150-200 cycles.
And an inc/dec may not necessarily need a lock if the array element is not
shared, even if you inc/dec the ref count.
D offers opportunities to go beyond traditional ref count eliding.
But even still, 150-200 extra cycles here and there is not as bad as a
300ms pause to collect garbage for some apps.
I think nobody is arguing that Ref counting is a magic bullet to memory
management. It fits some applications better than GC, that's all.
-Steve
