Possible @property compromise

[Rob T]

On Wednesday, 30 January 2013 at 05:22:06 UTC, 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.
>
> 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.

Yes, very good points. We're likely optimizing away for little to 
no gain most of the time, and maybe even making things worse not 
better in some cases.

--rt