topic Re: MOVE CORRESPONDING Vs ASSIGN Statement in Application Development and Automation Discussions

MOVE CORRESPONDING Vs ASSIGN Statement

Former Member — Thu, 08 Aug 2013 05:41:13 GMT

I have a huge dynamic structure which will have 300 fields data.

If I need to fetch 10 fields data from it I am doing as below.

300 fields structure is <lwa_hugestructure> - field1 to field300

10 fields structure is ls_required_data. - field3, 6, 9, 23, 56, 78, 89, 123, 145, 176.

Do I have to Prefer

MOVE_CORREOSPONDING <lwa_hugestructure> TO ls_required data.

ASSIGN COMPONENT 'FIELD3' OF STRUCTURE <lwa_hugestructure> TO <lv_value>.

IF sy-subrc EQ 0.

ls_required_data-field3 = <lv_value>.

ENDIF.

ASSIGN COMPONENT 'FIELD6' OF STRUCTURE <lwa_hugestructure> TO <lv_value>.

IF sy-subrc EQ 0.

ls_required_data-field6 = <lv_value>.

ENDIF.

ASSIGN COMPONENT 'FIELD176' OF STRUCTURE <lwa_hugestructure> TO <lv_value>.

IF sy-subrc EQ 0.

ls_required_data-field176 = <lv_value>.

ENDIF.

Please explain me.

Re: MOVE CORRESPONDING Vs ASSIGN Statement

Former Member — Thu, 08 Aug 2013 05:50:42 GMT

This message was moderated.

Re: MOVE CORRESPONDING Vs ASSIGN Statement

Former Member — Thu, 08 Aug 2013 05:55:14 GMT

Thank you Sravan for your quick reply.

My point in raising this question is to know which statement I should use to copy the data from huge dynamic structure to small structure.

Re: MOVE CORRESPONDING Vs ASSIGN Statement

Former Member — Thu, 08 Aug 2013 06:01:37 GMT

Hi Kishore

It is better to go with Assign Component rather than MOVE-CORRESPONDING .

As you need only 10 fields to be assigned to target fields out of 300 fields.

Re: MOVE CORRESPONDING Vs ASSIGN Statement

Former Member — Thu, 08 Aug 2013 06:06:50 GMT

Assign statement will have better performance compared to move corresponding...... My suggestion is to go for assign........

Re: MOVE CORRESPONDING Vs ASSIGN Statement

Former Member — Thu, 08 Aug 2013 06:15:47 GMT

Hi Kishore,

To add to Shravan's explanation,Assign is a better option than Move Corresponding

Re: MOVE CORRESPONDING Vs ASSIGN Statement

Former Member — Thu, 08 Aug 2013 06:21:29 GMT

Please explain me how assign is better than move-corresponding.

As far as i know we should use ASSIGN statement only when we are trying to modify the data, but here I am just moving the data.

Re: MOVE CORRESPONDING Vs ASSIGN Statement

kakshat — Thu, 08 Aug 2013 06:23:44 GMT

Hi Kishore,

Strictly speaking, the ASSIGN method would be better in terms of performance. BUT, if I were in a similar situation as you, I would have gone ahead with MOVE-CORRESPONDING because the difference in performance, in most cases, should be imperceptible to humans and maintenance of code would be much simpler. If you write as many ASSIGN statements as the number of fields, it becomes very tedious, especially when you have hundreds of fields as in your case. Perhaps you can try with MOVE-CORRESPONDING first and measure the time taken using tools like SAT/SE30.

Regards,

Akshat

Re: MOVE CORRESPONDING Vs ASSIGN Statement

matt — Thu, 08 Aug 2013 06:43:07 GMT

I entirely agree. I handle large dynamic structures all the time, in processes involving huge data sets. I first define a structure that contains only the fields I'm interested in. I then use move-corresponding to get the data from the dynamic structure to the defined structure. I used to use the field-symbol approach, but for ease of programming and maintenance, I've switched to Move-corresponding, and I've found NO significant difference in performance.

Anyway, sometimes field symbols are slower.

For example.

LOOP AT tab ASSIGNING <fs>.

ASSIGN field1 OF structure <fs> TO <field>.

...

ENDLOOP:

is slower than

LOOP AT tab ASSIGNING <fs>.

MOVE-CORRESPONDING <fs> TO mystruc.

...

MOVE-CORRESPONDING mystruc TO <fs>. " For any fields whose values have changed

ENDLOOP.

(You can get round this by defining the field-symbol for the work area, and using LOOP AT tab INTO <fs>)

Generally, MOVE-CORRESPONDING is better than field symbols as it is less prone to error, makes for code that is easier to maintain, and it makes debugging easier (it's difficult to set watch points on field symbols).

Field-symbols only make a significant performance improvement in certain specific cases. E.g. updating internal table contents.

Re: MOVE CORRESPONDING Vs ASSIGN Statement

Former Member — Thu, 08 Aug 2013 07:02:51 GMT

Matthew,

I was having a discussion with my colleague about this.

Actual discussion was::

Suppose if I want to move data from my huge dynamic strcuture <lwa_hugestrucuture> to ls_required_data.

I mean how the data is moved from source to target structure ?

First field field1 of source structure will be checked if it exists in the target structure and if it exists data will be moved and field2 will be checked in the same way.

first field field3 of target structure will be checked in the source structure if it exists data will be fetched and next field6 will be checked in the same way.

Please explain.

Re: MOVE CORRESPONDING Vs ASSIGN Statement

Former Member — Thu, 08 Aug 2013 07:20:32 GMT

Hi Kishore,

ASSIGN COMPONENT always check the field in the source structure. In the target we generally have a field where we store the value, and then we pass that value to the structure.

In MOVE-CORRESPONDING both the structures are checked, for the fields. If you have to transfer massive data, then move-corresponding is not the better option. You should use ASSIGN COMPONENT, but again if u use it its not easy to debug it everytime.

Re: MOVE CORRESPONDING Vs ASSIGN Statement

matt — Thu, 08 Aug 2013 08:15:58 GMT

Only the people who've written the ABAP language can tell you how the command works.

If you really want to know the fast way - write a test program. Then you can operate from fact rather than opinion or theory.

Even if field-symbols is quicker, performance is not the main priority for programming. Simple programming is to be vastly preferred. Only use complicated programming if:

a) It's been proven that the complicated programming is quicker and

b) It is critical that the best possible performance is squeezed from the program.

To do otherwise is bad programming. If you use the field-symbol alternative to move-corresponding, then you are writing code that it more complicated than it needs to be. More complicated code is harder to maintain, and takes longer to maintain, and is therefore more expensive.

Edit:

Testing with 100'000 records of a structure containing 173 fields, into a structure containing 15 fields.

1) Comparing move-corresponding with

ASSIGN COMPONENT field OF STRUCTURE <FS>.

....

LOOP AT itab INTO <FS>:

...

Field-symbols take 66% of the time of move-corresponding. Extrapolating to 10'000'000 records, that would mean using FS would save you 3 seconds).

2) Comparing move-corresponding with

LOOP AT itab ASSIGNING <fs>.

ASSIGN COMPONENT field OF STRUCTURE <FS>.

...

ENDLOOP.

Field-symbols are ten time slower than move-corresponding.

On this basis, if you're handling large quantities of data, it's still not worth using field-symbols over move-corresponding, unless performance is absolutely critical. If you're only handling a few records, then field-symbols are definitely not worth using.

Re: MOVE CORRESPONDING Vs ASSIGN Statement

Former Member — Thu, 08 Aug 2013 08:54:41 GMT

Thank you Matthew.

Re: MOVE CORRESPONDING Vs ASSIGN Statement

matt — Thu, 08 Aug 2013 08:58:38 GMT

I also checked the runtimes if the source structure has more fields than the destination and when the source structure has fewer fields than the destination. (Again 173/15 and 15/173).

I could find no significant difference in the runtime.

Re: MOVE CORRESPONDING Vs ASSIGN Statement

matt — Thu, 08 Aug 2013 08:59:15 GMT

Inaccurate.

Re: MOVE CORRESPONDING Vs ASSIGN Statement

matt — Thu, 08 Aug 2013 08:59:25 GMT

Inaccurate

Re: MOVE CORRESPONDING Vs ASSIGN Statement

Former Member — Thu, 08 Aug 2013 11:14:38 GMT

at times move-corresponding just makes life so simple for folks like me who have to so many times clean garbage code written by some brick heads but in my current company what makes me laugh is that some co workers behave as if thsi keyword causes plague these so called reviewers just see what they have been forced feed... there are so many cases i have seen where many ABAP keywords are treated with big bias.

in my case on any given day field symbol and the pointer based memory approach that idt does will be a boon with data intensive modify operations but one have to judge the situation in most assign a value case move-corresponding is perfect way and there;s no runtime impact

Re: MOVE CORRESPONDING Vs ASSIGN Statement

VXLozano — Thu, 08 Aug 2013 12:35:18 GMT

Just a question: it worths the effort to worry about it?

I mean: when I code, I have two goals in mind (money a part):

- the program must do what it is expected to do

- the program must be easily maintenable

Only when the program appears to have a very long execution time things like syntax performance will be took under consideration. And usually, things like your question will not make the difference.

Be worried about your program maintenance, the easy it is to be read and if the whole logical processes (LOOPs, READs and so) are fine. If your program takes 3 minutes to work, you don't need to care about use complex and hard-to-maintain code to lower it to 2 minutes 56 seconds...

(just my though)

Re: MOVE CORRESPONDING Vs ASSIGN Statement

matt — Thu, 08 Aug 2013 13:18:25 GMT

It's one of the myths of the ABAP world - same as "For all entries is better than Inner join", when in the vast majority of cases, it's the other way around. And, of course, inner join produces more readable code.

Re: MOVE CORRESPONDING Vs ASSIGN Statement

VXLozano — Thu, 08 Aug 2013 13:28:47 GMT

The old SDN had some nice blog posts about that. I'm sure they still will be around, somewhere. I ever though these things happen because old ABAPers were old-fashioned people used to work versus some hardware limits we don't have anymore. But old costumes are still here.

How many "new wave" programmers do you know who still use the bloody WITH HEADER LINE clause?