backporting features to D1

[Frank Benoit]

Christopher Wright schrieb:
> Frank Benoit wrote:
>> Christopher Wright schrieb:
>>> Jarrett Billingsley wrote:
>>>> Then address the issues of stack vs. heap delegates.
>>> That is not required for Tango to function properly with D2. It's a
>>> performance optimization only. A significant one, but no more.
>>
>> I disagree here.
>> If you use lambdas for filters in inner loops, that is a main
>> performance hit. It is more than just "optimization", it is a reason to
>> change the design. It is a reason not to use D2. It is a D2 show-stopper.
>> Even worse, no error message is showing you the problematic places, D2
>> just makes your heap explode.
>>
>> int findMyTypeXYZ( MyType[] a, int criteria ){
>>     int match = convCrit( criteria );
>>     return tango.core.Array.findIf( a, delegate bool(T e){ return
>> e.attrib
>> is match; });
>> }
>>
>> First this run without allocation, now it does allocate.
>> Image how this behave if called very often :(
>> And even worse, there is no way to manually delete the allocated stack
>> frames. So there is no way around the GC runs.
>> Finally I would end up in rewriting that code, not using a delegate
>> based design. But IMHO this is one of the important D features.
> 
> Well, how much of a performance hit is it?
> 
> If the average application will run half as fast, then this is a
> significant issue that should be addressed soon. But it will not prevent
> me from using Tango with D2 in the interim.
> 
> If it's a 100x performance hit, then I wouldn't expect a port of Tango
> yet. But I suspect that it's more like a 10-15% performance hit at most.
> (I am talking about a typical application. I'm sure you could get a
> benchmark that runs much slower by choosing library calls that make
> extensive use of delegates and using those constantly.) I don't know;
> nobody has given any ballpark figures, much less benchmarks.
> 
> I'm going to try porting some of my code to D2/Tango. I'll post the
> results.

How can you guess anything here?

Old behavior == just the direct call, no extra cost
New behavior == same direct call plus a heap allocation
                with unbound cost

There is nothing like a typical application. There is nothing like a
typical calling rate to full closures. Either you use them or you don't.
It depends on your code. So even if you port some code and do some
tests, there is no significant result for my code.

There _can_ be 100x performance hit. Code that was allocation free is
now no more. That is super bad.