topic Re: Which is Performance wise better MOVE or MOVE CORRESPONDING ... in Application Development and Automation Discussions

Which is Performance wise better MOVE or MOVE CORRESPONDING ...

Former Member — Thu, 26 Jun 2008 04:36:43 GMT

Hi SAP-ABAP Experts .

Which is Performance wise better ...

MOVE or MOVE CORRESPONDING .

Regards : Rajneesh

Re: Which is Performance wise better MOVE or MOVE CORRESPONDING ...

Former Member — Thu, 26 Jun 2008 04:38:03 GMT

<removed by moderator>

Edited by: Mike Pokraka on Aug 4, 2008 6:51 PM

Re: Which is Performance wise better MOVE or MOVE CORRESPONDING ...

Former Member — Thu, 26 Jun 2008 04:38:34 GMT

This message was moderated.

Re: Which is Performance wise better MOVE or MOVE CORRESPONDING ...

Former Member — Thu, 26 Jun 2008 04:41:06 GMT

Hi SAP-ABAP Experts .

Which is Performance wise better ...and Why ?

(a) MOVE or MOVE CORRESPONDING .

(b) Select single and Select up to one row

Regards : Rajneesh

Re: Which is Performance wise better MOVE or MOVE CORRESPONDING ...

Former Member — Thu, 26 Jun 2008 06:29:24 GMT

Hi,

it depends on how many fields you have in the internal table.

for less number of entries, it doesnt make any diff.

for more entries, say u want to move 10 field values into an internal table with 50+ fields, move corresponding will take slightly more time than MOVE.

so, its ur call now.

regards,

madhu

Re: Which is Performance wise better MOVE or MOVE CORRESPONDING ...

Former Member — Tue, 05 Aug 2008 06:57:55 GMT

move is better...

other option it need conversion soo

Re: Which is Performance wise better MOVE or MOVE CORRESPONDING ...

Former Member — Tue, 05 Aug 2008 11:11:55 GMT

> Select single will pick the first maching record, but Select up to one row will select the most accurate search criterial.

that is nonsense !!

There is no difference. Use Select single if the key is fully is fully specified, i.e. if only one record can fulfill the condition.

Use up to n rows if several can fulfill to condition, but you want only n. n=1 is the special case.

Note, if 'order by' is added then all records fulfilling the condition must be found, same with aggregates. The 'up to n rows' does not read all records by itself. Often stated differently here.

Move and move-corresponding:

Used what really fits your needs. Use 'move into' if both structures are identcial. Use 'move corresponding' if they are not.

Siegfried

Re: Which is Performance wise better MOVE or MOVE CORRESPONDING ...

Former Member — Wed, 06 Aug 2008 08:45:42 GMT

Hi Sigfried,

totally agree.

Performance is defined at design time: Consider a data model that has flaws in it : not relevant HOW you access the data; it will have poor performance by design.

The design should be that way that the most common queries your users send to the DB are as efficiently as possible: If you come out with a query containing nested joins and EXISTS several levels deep the design is poor...

Performance is defined before you create any table - decisions like wich fields belong together in one tuple, wich indexes are necessary, what data volume to expect (ever considered partitioning for a table?)

Tuning-after is really a pain : You really wouldn't want to change physical structures in a production system.

They follow then the 'Never change a running program' and get stucked with the poor performance.

Benchmark everything!

Small-scale benchmark your approaches for problem solving (The MOVE against the MOVE-CORRESPONDING).

big time benchmark with simulated concurrent users (10,100,1000,10.000)

Don't believe in "We always did it that way' and 'Everyone knows you should do it that way'

There can be said lot more about that...

Re: Which is Performance wise better MOVE or MOVE CORRESPONDING ...

ThomasZloch — Wed, 06 Aug 2008 09:08:03 GMT

> There can be said lot more about that...

all good, but I think the problem here is that many people don't have the correct ABC/top-down-approach to solve performance issues, as in

- use primary or secondary indexes when accessing database tables

- use sorted or hashed internal tables and access by key (or index where applicable)

- declare only required fields in target tables for array selects

- ...

- any circulating myth like "use FOR ALL ENTRIES" or "don't use MOVE-CORRESPONDING"...

Thomas

Re: Which is Performance wise better MOVE or MOVE CORRESPONDING ...

Former Member — Wed, 06 Aug 2008 15:01:19 GMT

Thomas is going in the right direction, I would add one point

access path and indexes
too large numbers of records or executions
processing of internal tables => no quadratic coding

these are the main performance issues!

> Performance is defined at design time

partly yes, but more is determined during runtime, you must check everything at least once. Many things can go wrong and will go wrong.

database does not what you expect
selections are empty, everything is read
quadratic coding is not only caused by nested loops, sometimes also by logic and other things.

.... there are several other topics ....

difference between SELECT SINGLE and SELECT UP TO 1 ROWS ..... is several microseconds

Siegfried

Re: Which is Performance wise better MOVE or MOVE CORRESPONDING ...

Former Member — Thu, 07 Aug 2008 03:44:05 GMT

yes this thread is answered .

Thanks for all Great replies .

Regards : rajneesh

Re: Which is Performance wise better MOVE or MOVE CORRESPONDING ...

Former Member — Thu, 07 Aug 2008 13:12:53 GMT

Rajneesh - you've asked enough questions to know that the proper way to say "thanks" in the SDN forums is by assigning points to the helpful answers.

Rob

Re: Which is Performance wise better MOVE or MOVE CORRESPONDING ...

Former Member — Tue, 12 Aug 2008 12:49:06 GMT

> all good, but I think the problem here is that many people don't have the correct ABC/top-down-approach to solve performance issues, as in

> A

> - use primary or secondary indexes when accessing database tables

I would put this into the data model design phase...

> - use sorted or hashed internal tables and access by key (or index where applicable)

> B

> - declare only required fields in target tables for array selects

> - ...

> C

> - any circulating myth like "use FOR ALL ENTRIES" or "don't use MOVE-CORRESPONDING"...

> Thomas

the others you have to benchmark in the implementation/development phase

Re: Which is Performance wise better MOVE or MOVE CORRESPONDING ...

Former Member — Tue, 12 Aug 2008 13:08:51 GMT

> A

> * access path and indexes

Indexes and hence access paths are defined when you design the data model. They are part of the model design.

> * too large numbers of records or executions

consider a datawarehouse environment - you have to deal with huge loads of data. a Million records are considered "small" here. Terms like "small" or "large" are depending on the context you are working in.

If you never heard of Star transformation, Partitioning and Parallel Query you will get lost here!

OLTP is different: you have short transactions, but a huge number of concurrent users.

You would not even consider Bitmap indexes in an OLTP environment - but maybe a design that evenly distributes data blocks over several files for avoiding hot spots on heavily used tables.

> * processing of internal tables => no quadratic coding

> these are the main performance issues!

> > Performance is defined at design time

> partly yes, but more is determined during runtime, you must check everything at least once. Many things can go wrong and will go wrong.

sorry, it's all about the data model design - sure you have to tune later in the development but you really can't tune successfully on a BAD data model ... you have to redesign.

If the model is good there is a chance the developers chooses the worst access to it , but then you have the potential to tune with success because your model allows for a better access strategy.

The decisions you make in the design phase are detemining the potential for tuning later.

> * database does not what you expect

I call this the black box view: The developer is not interested in the underlying database.

Why we have different DB vendors if they would all behave the same way? I.e. compare concurrency

and consistency implementations in various DB's - totally different. You can't simply apply your working knowledge from one database to another DB product. I learned the hard way while implementing on INFORMIX and ORACLE...

Re: Which is Performance wise better MOVE or MOVE CORRESPONDING ...

ThomasZloch — Tue, 12 Aug 2008 13:26:25 GMT

You seem to have good knowledge in the areas you're referring to.

Most of the time here though, people use the already modelled and designed SAP standard data model in a wrong way and come here with their problems. E.g. "my report dumps with TIME_OUT", because they are selecting on BSEG without the primary key. Simple as that. I'm afraid these fundamental theories, while correct, won't help the poor chaps with their specific problems.

Cheers

Thomas

Re: Which is Performance wise better MOVE or MOVE CORRESPONDING ...

Former Member — Tue, 12 Aug 2008 13:38:01 GMT

Hi Thomas,

that's sad but true. I know I here them calling for more CPU , faster disks...

Because I'm in the business of performance tuning often when I'm called they already

have gone through this stage...spent a lot of money only to hit the next

limit because there is no scalability in the model nor in the application.

The worst thing is when the design is bad and you can't change - you are stuck to it.

- Well, you can index... and over index

- or sometimes go the "hard" native SQL way

bye yk

Re: Which is Performance wise better MOVE or MOVE CORRESPONDING ...

ThomasZloch — Tue, 12 Aug 2008 13:45:39 GMT

True. Some of my income derives from fixing bad designs though, so I should not complain too much.

Re: Which is Performance wise better MOVE or MOVE CORRESPONDING ...

nishantbansal91 — Tue, 19 Nov 2013 19:47:04 GMT

This message was moderated.