These performance questions of mine are more questions in how the mechanism works than that I worry about the speed.

On Sat, Sep 20, 2008 at 1:48 PM, Saaa <empty@needmail.com> wrote:
> :D
> Looks cool!
> No way I could have come up with that.
> Same question (as I have no clue how this internally works):
> Is there a performance penalty?
>

No more than any other method that uses delegates; it's just a bit of syntax abuse to call a function.

Delegates work by passing an implicit context pointer to the nested function as a parameter.  Nested functions use a pointer to the stack frame of the enclosing function as the context pointer, so they can access the local variables of the enclosing function.  There is a performance penalty for calling delegates just as there is for calling functions through function pointers: it may cause a processor pipeline stall.  However with the preponderance of object-oriented programming in which calling virtual methods involves calling functions through pointers, many modern processors have been so heavily optimized for it that the performance difference from hard-coding the function address into the code is negligible.  Not nonexistent, but definitely better than it used to be.

And besides -- you're calling that delegate once, so it'll be just a constant time overhead.

On Sat, Sep 20, 2008 at 2:40 PM, Jarrett Billingsley <jarrett.billingsley@gmail.com> wrote:
> On Sat, Sep 20, 2008 at 1:48 PM, Saaa <empty@needmail.com> wrote:
>> :D
>> Looks cool!
>> No way I could have come up with that.
>> Same question (as I have no clue how this internally works):
>> Is there a performance penalty?
>>
>
> No more than any other method that uses delegates; it's just a bit of syntax abuse to call a function.
>
> Delegates work by passing an implicit context pointer to the nested function as a parameter.  Nested functions use a pointer to the stack frame of the enclosing function as the context pointer, so they can access the local variables of the enclosing function.  There is a performance penalty for calling delegates just as there is for calling functions through function pointers: it may cause a processor pipeline stall.  However with the preponderance of object-oriented programming in which calling virtual methods involves calling functions through pointers, many modern processors have been so heavily optimized for it that the performance difference from hard-coding the function address into the code is negligible.  Not nonexistent, but definitely better than it used to be.
>
> And besides -- you're calling that delegate once, so it'll be just a constant time overhead.
>

I suppose I should also mention that if you're using D2, delegates will secretly allocate outer functions' local variables on the heap if nested functions access them.  There is currently no way in D2 to achieve the efficient D1 behavior of always keeping the stack frame on the stack.

As to how it works.  The t.bindBlock() in {...} can be rewritten using C++-like syntax:

void worker()
{
    // some rendering code!
}
BindBlock bb = t.bindBlock();
bb.opIn(&worker);

The code below simply writes all this in one line using a temporary BindBlock structure, an overloaded operator 'in', and an inline anonymous delegate syntax.

Saaa <empty@needmail.com> wrote:
> :D
> Looks cool!
> No way I could have come up with that.
> Same question (as I have no clue how this internally works):
> Is there a performance penalty?
> 
> > How about a horrible/wonderful misuse of the 'in' operator?  (credited
> > to Tom S):
> >
> > class Texture
> > {
> > ...
> >    struct BindBlock
> >    {
> >        Texture self;
> >        void opIn(void delegate() dg)
> >        {
> >            self.bind();
> >            scope(exit) self.unbind();
> >            dg();
> >        }
> >    }
> >
> >    BindBlock bindBlock() { return BindBlock(this); }
> > ...
> > }
> >
> > auto t = new Texture("foo.png");
> >
> > t.bindBlock() in
> > {
> >    // some rendering code!
> > };

Saaa wrote:
> These performance questions of mine are more questions in how the mechanism works than that I worry about the speed. 

Delegate performance should be no worse than virtual method invocation. You're passing a pointer to a function, whereas virtual method invocation is effectively passing a pointer to a pointer to a function.

Thanks all!