Chad J wrote:
Chad J wrote:
Bill Baxter wrote:
On Wed, Jul 29, 2009 at 1:14 PM, grauzone<[email protected]> wrote:
Chad J wrote:
Thinking about it a little more, the extra temporaries could run you out
of registers. That still sounds like a negligable cost in most code.
Temporaries can be on the stack. That's not a problem.
How is that not a performance issue? The stack is in main memory.
--bb
This is where my knowledge starts to run a bit thin.
So correct me if I'm wrong, but isn't something like the stack (or at
least the top/bottom/end in use) extremely likely to be in the nearest
cache (L1)?
If that's the case, then this kind of dereference is going to be of the
cheaper variety.
Also, really deep dot chains are unlikely to happen. I just feel like
this won't create many more memory accesses than there were already.
Especially for people with 64 bit OSes on x86_64 that are not register
starved like the 32 bit x86. On x86 you are hitting the stack all the
time anyways, and the extra access or two will go unnoticed.
Especially especially because, if you prevent the a.b.c = x syntax, the
only thing that'll happen is you'll cause people to write all that code
themselves. The same number of assignments will happen anyhow, but the
user will have to write them all manually. I'll all for having the
compiler automate the boilerplate stuff.
Also, note that the double-assignment case only happens when assigning
to value types. Assigning to reference type properties will be unaffected.
--benji
