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

[Former Member]

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

[Former Member]

Does this help?

http://help.sap.com/saphelp_47x200/helpdata/EN/9f/db98ef35c111d1829f0000e829fbfe/frameset.htm

Rob

[Former Member]

No, I'm afraid that is not helpful. It does not address the specifics of how passing by value deals with tables. Also, it is not necessarily clear that functions would work exactly that same as methods in this respect, since this is such a specific detail.

Thanks though,

-Chris

[Former Member]

Hi,

Returing value provides a value. Program needs to capture a returning value. This returning value is of certain data type. Thus data object of type of returning value should be used to capture the value. Hence, reference value is not allowed for returning parameter. The type of the returning parameter is already known.

Consider the case of Importing, changing and tables parameters. These parameters can be passed by reference or by value.

A method can access the data by refernece. In this case data objects need not be defined locally in the mehtod. Method will take the reference of the data object specified and reads the value. Thus, extra memory will not be allocated for data objects in the method. This increases the performance.

Regards,

Vara

[Former Member]

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!

[former_member183804]

Hello Christopher,

the mechanism you have discovered is called table sharing. Please note with current releases it works with table only, that means tables contained in a structure get copied.

Best Regards

Klaus

[Former Member]

Thank you so much, Klaus! That is good information to know. Also, it is reassuring to know that what I said was basically correct.

[former_member474405]

Hi Klaus,

you mentioned "in the current releases". Are there plans to enhance this feature also to tables contained in structures? And if so, also to downport this change to "the current releases"? If yes, it would be (at least in some cases) an option to live with the performance overhead until then in order to keep code better readable...

Best regards,

Manuel

[former_member194613]

>downport this change to "the current releases"

what are current releases? What would you expect?

I doubt that there will be a downport at all. And additionally it is probably not even possible as it might be based on newer kernel functions. I doubt that there is more communication.

[Former Member]

See my last post to the thread for the solution.