GC allocation

[Alex via Digitalmars-d-learn]

On Friday, 22 April 2016 at 01:55:36 UTC, Adam D. Ruppe wrote:
> On Thursday, 21 April 2016 at 22:59:58 UTC, Alex wrote:
>> Ok... I make slices of them, carefully avoiding to make 
>> copies...
>
> Yeah, that shouldn't make a difference..

Wait, wait... I try to make slices of the array of delegates, 
because I thought the slicing operation is cheaper, then another 
possibilities... And I try to make them as little as possible.

>
>> Huh? I think, this is the place, where I lack some 
>> background... So, I bind my delegates via
>
> Can you post any more of your code?

Sure. Which part? ;)
the delegate is defined directly in a model as
uint dDelegate(uint id, MM p);

and the method delegateDefinition inside the binding responsible 
class has a form like
uint delegateDefinition(uint id, MM p)
{
     uint retVal;
     final switch(p) with(MM)
     {
         case first: return callSomeFuncFromThisObject(id); break;
         case second: return id; break; // this the one and only 
case, which is unusual
         case third: return 
knownObjectByThisObject.callAnotherFunc(id); break;
     }
}

And a slice returning method inside the responsible class has a 
form like
typeof(.delegates) getSlice(uint i)
{
     uint first = someLogic(i);
     uint last = someOtherLogic(i);
     return .delegates[first .. last];
}

Indeed, the getSlice operation is the slowest, because of the 
getting the first and the last operations. So I reduce the calls 
to slice returning methods to this one and only method. And I 
call it as rare as possible.
But I hope the slicing itself does not copy anything which is 
seen anyway by every other object. The getSlice method should 
just return the proper, well, slice, based on the given input.

>
>>     return iota(delegatesAmount).map!(a => (MM p) => 
>> .dDelegate(a, p));
>
> This would indeed allocate a new heap block for each one, but 
> there might be other ways to do it.
>
>> Yes. I'm sure the object is alive till the very end. As 
>> mentioned above, do you think it is worth to make a struct to 
>> save a result from iota?
>> Nevertheless, my intention here is speed, so a fast solution 
>> is much better, then any slow one, even if the speed gain is 
>> 10% only... But the construction effort is almost negligible.
>
> I don't know yet, if construction is allowed to be slower, what 
> you have is fine though.

Cool :)
Thanks!