Returning Internal Table as Returning Parameter of Method (by Value).

Question

When you return an internal table as the returning parameter of a method, it is passed by value.  I understand the concept of passing by value vs. passing by reference, but exactly what this means in this case is ambiguous.
1)  It could mean that the entire table, including data, is copied from the local table in the method into the parameter provided by the calling code.
2)  Alternatively, it could mean that only the pointer to the table is passed by value and the data is not literally copied from one place in memory to another.  This would <b>not</b> be the same as passing by reference.  For instance, I believe this is how object references are passed by value.
I want to know how it works, so that I know if there is an efficiency problem with returning a huge table.  The returning parameter is wonderful for getter methods, and I prefer to use it over exporting parameters, but I have some concern about passing tables as returning parameters since I don't know how this works.
Can anyone either explain this, or at least make it clear to me whether or not there is an efficiency issue?
Thanks, in advance,
-Chris

Answer 1

Thanks to those who tried to help me with this question, but I finally had to just figure it out on my own.  I just realized today that there is a way to find the answer using the debugger's <i>Go To->Status Display->Memory Use</i> option.  This shows how variables are stored in memory.
The answer:
First of all, if you set one internal table equal to another like:
  i_tab1 = i_tab2.
or like:
  i_tab1[] = i_tab2[].
both will simply set <i>i_tab1</i> to point to the same memory that <i>i_tab2</i> is using.  It does <b>not</b> make a copy.  Now, if you attempt to change <i>i_tab1</i>, with an <i>append</i> statement for instance, a copy of <i>i_tab2</i>'s memory is made <b>then</b>!  The requested change to <i>i_tab1</i> is then applied to the copied data.  <b>AHA!!!</b>  This means that even if you think you are copying a table, you are not really doing it until it becomes necessary due to a divergence in values.
I specifically tested a returning parameter to see how memory is handled, and it is basically just like an '<i>=</i>' statment.  No copy of the data is performed at first.  The memory that is allocated for the local variable in the method is simply pointed to by the variable used in the calling code to recieve that value.
What if you then change the value in the calling code after the method has finished executing?  The answer depends on the situation.  If the value that you returned from the method is still being pointed to by another variable somewhere, then a copy is made when you attempt to change the returned table in the calling code, but if there is no longer another variable pointing to this memory, you can change the table in the calling program all you want without causing a copy in memory.
For instance, if you have a getter method that returns the value of an attribute, at first no copy will be made, but when you try to change the table in your calling code, a copy will be made then.  However, if you just fill a local table in your getter method and return that table, there will never be a copy made, because the local variable that originally pointed to that memory expired when the method completed.  That means that after the method completes, the only variable pointing to the allocated memory is the one in the calling code that recieved the returning value.
This is fantastic!!  This behaives in a way that seems to provide maximum efficiency in most cases.  Also, the table copies are <b>never</b> a waste, since they only happen upon changing of one of the table variables that point to the common memory, and in this case you would <b>want</b> to make a copy to avoid corrupting the other variable.
Also, even if you did return your table as an exporting parameter by reference, you would not gain any significant efficiency.  There would still be no table copy if you don't change the returned table.  Also, if you did change the returned table, you <b>would</b> still produce a table copy if there was another variable, like an attribute, still pointing to the memory that you set your exporting paramter from before.
The only situation that I can see resulting in a needless efficiency problem is if someone used a getter method to return the value of a table attribute, then changed the returned table in the calling program, and then used a setter method to set the whole table attribute equal to the changed table.  This would be a waste, so maybe this should be accomplished in another way.
In conclusion, there is essentially no reason to hesitate returning a whole internal table as a returning parameter from a method call, even though it is pass by value.
Kudos to the ABAP development team for their good design!