DIP60: @nogc attribute
Steven Schveighoffer via Digitalmars-d
digitalmars-d at puremagic.com
Fri Apr 18 07:15:00 PDT 2014
On Fri, 18 Apr 2014 10:00:21 -0400, Ola Fosheim Grøstad
<ola.fosheim.grostad+dlang at 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
More information about the Digitalmars-d
mailing list