On Thu, 15 Oct 2009 07:45:02 -0400, Justin Johansson
<[email protected]> 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
