About ref used for performance reasons with struct
deadalnix
deadalnix at gmail.com
Mon Feb 11 09:51:29 PST 2013
On Monday, 11 February 2013 at 17:15:40 UTC, Maxim Fomin wrote:
> On Monday, 11 February 2013 at 06:52:33 UTC, deadalnix wrote:
>> Ok, We have 2 usages of ref : when you actually need to modify
>> informations, and for performance reasons. Let's talk about
>> the second one.
>>
>> Passing by ref to improve performance is not ideal. First this
>> is quite hard to know when it is actually faster to pass by
>> ref and to pass by value, especially in generic code. Secondly
>> it is easy to forget to use ref at some location, and a lot of
>> small performance improvement are lost in the process.
>> Finally, this may be error prone.
>>
>> I'm thinking about it for a while now and I'm now convinced
>> that we should allow the compiler to do that job for us. Let
>> me explain.
>>
>> When a function accept a struct, the compiler is free to use
>> that function, or an altered one taking a reference as
>> parameter. Here are some rules the compiler can use to know
>> which one to call from callee side :
>
> I expect this to be a nightmare for both users, who would
> experience new pile of struct bugs and for developers. How much
> code would this proposal break?
>
None.
> What do you mean by 'altered'? Are you taking about two
> function versions or a single one? If first, how does it work
> with linking, and if second, how does it work for different
> situations? What happens when you use function pointer or a
> delegate? How __traits works with respect to function type in
> case of such optimization? What happens if compiler cannot
> deduce from context information required to make such decision?
> How does it play with variardic functions? And how such
> optimization can be disabled?
The optimization cannot be used on opaques calls. This include
function pointer and alike. The only function that is guaranteed
to exist is the one that take the struct by value. The other one
is an option that the compiler is allowed to choose to make
things faster.
It is applicable for variadic function for non variadic argument,
not for variadic arguments.
Finally, why would you disable something that make your code
faster ?
More information about the Digitalmars-d
mailing list