Possible @property compromise

H. S. Teoh hsteoh at quickfur.ath.cx
Tue Jan 29 22:39:21 PST 2013


On Wed, Jan 30, 2013 at 06:22:05AM +0100, deadalnix wrote:
> On Wednesday, 30 January 2013 at 04:57:15 UTC, Jesse Phillips wrote:
> >I don't agree with the argument that properties provide a convince
> >to identify low overhead access. While I'm not experienced in this
> >area, profile code should indicate where performance is poor, it
> >would be bad to assume "that looks like a field, so it must not be
> >where the performance is bad."
> >
> 
> Yes, this is true, like always. Even when property isn't involved.
> 
> Fectching memory that isn't in cache anymore is typically 200-250
> CPU cycles on modern x86 architecture. Getting that from a register
> is immediate. Accessing a variable has unknown cost, and only
> profile can reveal the truth here.

+1. Too many C programmers (including myself) have preconceived notions
about what is efficient and what isn't. Unfortunately, we're wrong more
often than we'd like to admit. When we actually run the profiler and get
real profile data, it often points to hotspots that are far, far away
from where we thought they were. We inherited this premature
optimization mindset from the CPUs of the 70's and 80's; today's CPUs
have far different performance characteristics, and our preconceived
notions are mostly all wrong.


> Considering that property/function have some importance in regard of
> performance is in complete contradiction with how computer and code
> actually work now.
> 
> The difference is semantic. In case of property, you think data, in
> case of function, you think action.

+1. The voice of reason.


T

-- 
I'm still trying to find a pun for "punishment"...


More information about the Digitalmars-d mailing list