What's up anyway -

Steven Schveighoffer schveiguy at yahoo.com
Thu Oct 15 05:10:59 PDT 2009


On Thu, 15 Oct 2009 07:45:02 -0400, Justin Johansson  
<procode at adam.com.after-dot-com-add-dot-au> wrote:

> downs Wrote:
>
>> Justin Johansson wrote:
>> > - that the .sizeof a delegate is 8 bytes (on a 32-bit machine).
>> >
>> > AFAIK, stack pushes are still more expensive than a pointer  
>> dereference in contemporary
>> > CPU architectures.
>> >
>> > Justin
>>
>> - with this weird way of writing posts? The subject should tell us  
>> about the content, not your emotional state! :p
>
> Re subject line: fair call, you are right.  Emotions aside, at least  
> this time I got a response.

You got a response because I'm actually awake and at a computer :)  I  
don't think you should expect much earlier than 7am eastern from the US  
participants (regarding your 3 am post about a manifesto, followed by an  
assumed lack of interest at 5 am).

But I have to agree with downs.  Although I look at "non-descriptive"  
posts, it has nothing to do with my likelihood of reading *or*  
responding.  Attributing response to changing such a non-essential piece  
of a post is like thinking you made it rain by dancing.

>
>>
>> Also I have no idea what you mean. Should delegate _values_ be heap  
>> allocated?! That'd be insanity. Also, I'm fairly sure you're wrong. The  
>> stack is relatively likely to be in the CPU cache. A random pointer  
>> dereferencing .. isn't. Also, do you really want to heap even more work  
>> on the ailing GC?
>
> I will be bold and say yes to off-stack allocation,
> whether that be in the general heap or other (and probably other to  
> avoid an "ailing CG").

When the majority of delegates survive exactly one function call, I think  
you might be very much wrong.  You only save on allocation vs. stack when  
you pass it through many function calls.  In fact, using such a delegate  
will probably be more penalized if the memory location is not local (and  
stack usually is close to the cache), not to mention putting it off stack  
means an additional pointer dereference.

> When the tough gets going, the going have to get tough.
> (Meaning to start thinking outside of the square.)

The going isn't tough yet :)  delegates work just fine for me.

-Steve



More information about the Digitalmars-d mailing list