On Friday, 31 January 2014 at 19:08:10 UTC, Andrej Mitrovic wrote:
On Monday, 31 December 2012 at 14:05:01 UTC, Kiith-Sa wrote:
All you have to do is care about how you allocate and, if
GC seems to be an issue, profile to see _where_ the GC is being
called most and optimize those allocations.
Bumping old thread:
There is an ever-increasing amount of newcomers in #d on IRC
who end up asking how to avoid the GC or at least to be able to
determine where implicit allocations happen. I think we should
work on creating a wiki page and gather as much advice as
possible on dealing with the GC, implicit allocations,
real-time constraints, etc.
We should concentrate on implementing scope. scope could prevent
many of such things.
E.g.:
{
scope int[] arr = new int[count];
}
Since scope shall guarantee that the marked variable does not
leave the scope, the compiler could safely assume that arr
shouldn't handled with the GC.
With that information the code could safely rewritten to:
{
int* tmp_arr_ptr = cast(int*) calloc(count, int.sizeof);
scope(exit) free(tmp_arr_ptr);
int[] arr = tmp_arr_ptr[0 .. count];
}
So no need to invoke the GC.
Since many objects have a small lifetime it is preferable to
avoid the GC. With scope the user could mark such objects... and
everyone wins. It is not perfect and does not cover all use cases
but it would be a start.
Sadly I doubt that scope gets implemented (soon). And since scope
classes was replaced with an ugly library solution I seriously
doubt that this nice dream comes true. But it would be so nice. :)
