Re: Efficiency of returning big objects

["Alex R. Mosteo" <devnull@mailinator.com>]

Dmitry A. Kazakov wrote:

> On Mon, 25 Sep 2006 14:14:44 +0200, Alex R. Mosteo wrote:
> 
>> I had a concern over the efficiency of returning big (tagged) types,
>> since I like to store them in indefinite collections (a la Object'Class)
>> instead of storing pointers to them. It is said that, as tagged types are
>> passed by reference, they are always efficiently passed around. However,
>> when you are /returning/ and not calling, I had my doubts, so I have made
>> this simple testcase (see at bottom).
> 
> Same with arrays - when returning a slice of a non-local string, GNAT
> copies it. It does this even when the callee is inlined.
>  
>> It has been compiled with just gnatmake -O3. It reveals that a copy is
>> created in the stack for returning every time. I was hoping that, as long
>> as the type were used as a constant, a reference would be returned and
>> passed around. This would be very interesting in collections, since we
>> could do, for example:
>> 
>> Some_Map.Element (Key).Method_Or_Member
>> 
>> without efficiency penalties.
>> 
>> Now, in C++ I would force this behavior explicitly returning references
>> (I guess this is the usual practice, but I'm not sure). In Ada, I have no
>> idea how to match this efficient behavior.
> 
> In Ada 2006 an equivalent would be an anonymous access type of the result.
> As ugly as C++, but works.

Yep, it is ugly and sadly(?) missing from the standard library. Also makes
current gnat go boom with relative easiness.

I've experimented with it recently and having both functions (return the
proper type and an access to it) leads to ambiguities, so I finally end
doing

Some_Function.all.blah 

to disambiguate, which is even uglier.

>> So, what do you think? Is there some error in my reasoning or testbed? Is
>> this a particular shortcoming of this compiler (gnat gpl 2006), or I'm
>> overlooking something that makes this very non-trivial to implement?
> 
> You mean, checking if the scope of the name of the function result is in
> the scope of the object returned? It is a global + temporal variables
> optimizations, AFAIK. And the callee should be inlined. [ However, I
> suppose, GNAT would make a copy even if your Create were inlined. ]

Just in case I've tried with -O3 -gnatn and -O3 -gnatN, and no differences.

Last time I did serious C++ (several years ago) I remember that returning
references was prone to give warnings about temporary copies being
necessary in some cases. I think this is precisely what we are talking:
when it is determined that a reference won't suffice because the returned
value will outlive the original reference, the warning is issued (and
copies made).