Dynamic Closure + Lazy Arguments = Performance Killer?

[Bill Baxter]

On Sat, Oct 25, 2008 at 5:24 PM, Jason House
<jason.james.house at gmail.com> wrote:
> bearophile Wrote:
>
>> Jason House:
>> > The following spends 90% of its time in _d_alloc_memory
>> > void bar(lazy int i){}
>> > void foo(int i){ bar(i); }
>> > void main(){ foreach(int i; 1..1000000) foo(i); }
>> > Compiling with -O -release reduces it to 88% :)
>>
>> I see. So I presume it becomes quite difficult for D2 to compute up to the 25th term of this sequence (the D code is in the middle of the page) (it takes just few seconds to run on D1):
>> http://en.wikipedia.org/wiki/Man_or_boy_test
>>
>> What syntax can we use to avoid heap allocation? Few ideas:
>>
>> void bar(lazy int i){} // like D1
>> void bar(scope lazy int i){} // like D1
>> void bar(closure int i){} // like current D2

This makes no sense because the writer of bar has no idea whether the
caller will need a heap allocation or not.

> I would assume a fix would be to add scope to input delegates and to require some kind of declaration on the caller's side when the compiler can't prove safety. It's best for ambiguous cases to be a warning (error). It also makes the code easier for readers to follow.

I think for a language like D,  hidden, hard to find memory
allocations like the one Andrei didn't know he was doing should be
eliminated.  By that I mean stack allocation (D1 behavior) should be
the default.  Then for places where you really want a closure, some
other syntax should be chosen.  The other reason I say that is that so
far in D I've only very seldom really wanted an allocated closure.  So
I think I will have to use the funky no-closure-please syntax way more
than I would have to use a make-me-a-closure-please syntax.

But apparently nobody who knows anything about what's actually going
to happen is involved in this discussion, so I think I'll just pipe
down for now.

--bb