Inlining Ref Functions

[Bill Baxter]

Well it was shown before in a demo ray-tracer that the inability to
inline funcs with refs caused a significant speed hit under DMD.  And
now we're seeing it's causing a significant speed hit for sorting
because of swap routines.

There may be some thorny issues regarding inlining with refs in the
general case but with code like this:

    float lengthSqr(const ref vec3 v) { return v.x*v.x + v.y*v.y + v.z*v.z; }

 it really should be trivial for the compiler to figure out that
direct substitution is possible in a simple case like:

   vec3 w;
   ...
   auto len2 = lengthSqr(w);

Maybe I'm missing something, but that looks pretty darn straightforward.

--bb

On Fri, May 15, 2009 at 2:01 PM, dsimcha <dsimcha at yahoo.com> wrote:
> == Quote from Bill Baxter (wbaxter at gmail.com)'s article
>> On Fri, May 15, 2009 at 1:36 PM, dsimcha <dsimcha at yahoo.com> wrote:
>> > The fact that DMD does not inline functions with ref parameters has come
>> up
>> > several times deep in threads on this NG before, but it's never really
>> > received proper attention.  After changing a few swaps in performance-c
>> ritical
>> > areas of my code to "manually inlined" swaps and seeing significant speed
>> ups,
>> > I'm kind of curious what the rationale is for not inlining functions w/ r
>> ef
>> > params.  Is there a good technical reason for this or is it simply a ma
>> tter of
>> > having higher priorities?  Is inlining functions w/ ref params on the "
>> to do
>> > eventually" list?
>> +1 on bumping up the priority on it.
>> Even if it it can't be made to work in every case, if it could at
>> least be made to work in simple cases like swap() then it would be
>> great boon for DMD benchmarks.
>> --bb
>
> Just to clarify:  I actually don't think this is a terribly high priority item.
> Now that D2 is apparently pretty much feature complete, I'd rather bug fixes for
> functionality bugs than relatively mild performance bugs.  My question was purely
> out of curiosity.
>