ABAP程序效率优化系列之②——开发优化之ABAP时间

ABAP程序效率优化系列文章历史

开发层面的优化内容太多，但目的只有一个，提高效率，节省时间。

说到运行时间，我们可以用事务代码SE30或SAT进行分析，并且知道它主要包括：

ABAP时间

各种排序、查找、循环、计算、赋值、判断、调用、内表操作等

数据库时间

数据库的读、写时间

(上一次我说HANA不能解决全部性能问题，就是因为HANA只是解决了大部分的数据库时间问题，并且结合HANA的特征来编写报表程序的时候，可以在一定程度上降低内表的数据量，所以HANA对ABAP时间优化也有贡献，但ABAP代码如果不做优化，执行时间依然是很长的)

这一期我主要分享自己关于ABAP时间优化的经验。

本人能力有限，但本着力求全面的精神，还是把一些老生常谈甚至意义不大的代码建议贴在这里：

(说明：

1、本次为ABAP时间优化的代码建议，SQL部分的在下一次分享

2、红色加粗的代码建议，带来的提升极为明显

3、有一部分代码建议虽然用途不大，但由于SE30的建议里提到了它们，所以我就列出来了，并标注为灰色。但不可否认，它们是属于良好的编码习惯)

使用MOVE代替MOVE-CORRESPONDING

内表合并

如果是结构一致的内表，用APPEND/INSERT LINES OF itab1 TO / INTO itab2.

根据普通表构建哈希表或排序表

1、根据一个内表构建不同结构的另外一个内表时，如果无特别需求，建议构建HASHED TABLE。因为INSERT wa INTO TABLE itab2，对于HASHED TABLE比SORTED TABLE更快。

2、根据一个内表构建相同结构的SORTED或者HASHED TABLE，使用排序->排重->INSERT LINES OF itab INTO TABLE itab2的方式更快。

READ STANDARD TABLE

尽量排序后使用二分查找(BINARY SEARCH)，特别是在循环中

READ时使用哈希表和排序表

1、如果是单条记录读取，建议使用HASTED TABLE(如：READ itab WITH (TABLE) KEY)

2、如果是对部分连续的数据读取，建议使用SORTED TABLE(如：LOOP AT sorted_itab WHERE key = value)

3、如果是在循环某大型内表itab2时通过READ读取itab1的数据，可以把itab1构建为SORTED/HASHED TABLE(根据前两条的说明，自行选择构建SORTED或HASHED TABLE),再通过READ读取构建后的SORTED/HASHED TABLE，甚至可节约ABAP时间90%。

参见SE30的提示与技巧->Internal Tables->Simple Algorithms->Intersection of internal tables

内表循环和嵌套循环(嵌套循环优化能带来极大提升，最为重要)

1、对于STANDARD TABLE和HASHED TABLE，应完全避免在内层循环中使用LOOP AT WHERE语句

2、对于SORTED TABLE，可以使用LOOP AT WHERE语句

3、对于HASHED TABLE，其优点在于单条数据的读取速度极快，但在嵌套循环的内层循环中使用哈希表并无优势，与STANDARD TABLE的性能无区别

4、对于STANDARD TABLE，应按以下方式使用：

SORT itab2 BY field1 field2."首先按条件字段排序

LOOP AT itab1.

READ TABLE itab2 WITH KEY field1 = itab1-field1 field2 = itab1-field2 BINARY SEARCH TRANSPORTING NO FIELDS."二分查找，确定满足条件数据的索引位置

"强迫症朋友请在此CHECK SY-SUBRC = 0，但没必要判断

LOOP AT itab2 FROMSY-TABIX.

IF itab2-field1 itab1-field1 OR itab2-field2 itab1-field2.

EXIT.

ENDIF.

ENDLOOP.

ENDLOOP.

更多原因分析、测试代码及结果，请参见我的BLOG文章：

http://www.cnblogs.com/abap-ll/p/5053390.html

按条件更改内表的字段

普通写法：循环内表，判断条件，更改内容。

优化写法：

wa-datum = sy-datum.

wa-uzeit = sy-uzeit.

MODIFY itab FROM wa TRANSPORTING datum uzeit WHERE flag IS INITIAL.

需要在循环中修改内表时，使用ASSIGNING更快

即LOOP AT itab ASSIGNING 优于 LOOP AT itab into wa. MODIFY itab FROM wa.

构建有嵌套结构的内表(内表套内表)

1、自上而下策略：先构建外层内表，然后循环外层内表，通过ASSIGNING的方式构建每一行的数据及内层内表。

2、自下而上策略：先构建每一行的数据及内层内表，再APPEND到外层内表中。

分析：“自上而下”优于“自下而上”。自下而上，会多一步MOVE“内层内表”到“外层内表工作区”的操作。当外层内表包含的条目数越多，包含的内层内表越多，内层内表的行项目数越少的时候(外层内表大、内层内表小)，自上而下的效率提升越明显；否则不是太明显，毕竟只多一步MOVE的操作。

参见SE30中INTERNAL TABLES->USING the Assigning Comand

COLLECT

1、在LOOP循环中使用READ读取相同主键的值，然后ADD，APPEND。

2、在LOOP循环中，COLLECT内表数据到目的表中。

方式2更快，COLLECT采用哈希算法（特别是针对1000条以上的数据）。

FORM定义

定义时，FORM的参数尽量都有参照类型，这样在FORM中使用传入传出参数时可节省约50%的处理时间。

即便FORM调用出现在循环中，次数非常多，耗用时间也不是特别多。效率提升有限

IF和CASE

条件多的时候，尽量使用CASE。

如：8个条件时，可节约70%的处理时间；3个条件时，也可节约近50%的处理时间；即便是1个条件，CASE也比IF快。

字符比较

字符和数字比较 慢于 字符和字符比较。

同理，字符和数字比较 慢于 数字和数字比较。

比较时，尽量采用同类型。

DO和WHILE

DO-EXIT-ENDDO. 慢于 WHILE-ENDWHILE.

CASE和PERFORM i OF

1、CASE I. WHEN 1. PERFORM PV1. WHEN 2. PERFORM PV2. ENDCASE.

2、PERFORM i OF PV1 PV2. [i代表pv1、pv2...的索引]

方式2更快。

N类型和P类型

建议N类型只是纯数字的字段定义，而不要进行算术运算，如电话号码、日期或时间值中的一部分等。P类型和其他数字类型，用来进行算术运算。

混合类型

例1：DATA: F1 TYPE I VALUE 2,F2 TYPE P DECIMALS 2 VALUE '3.14',F3 TYPE F.F3 = F1 * F2.

例2：DATA: F1 TYPE F VALUE 2,F2 TYPE F VALUE '3.14',F3 TYPE F.F3 = F1 * F2.

例1 慢于 例2.

尽量不要使用混合类型定义。

FORM、FUNC、LCL、CL

调用时：LCL优于FORM优于CL优于FUNC

CHECK和IF

CHECK比IF快

下一期，重头戏：开发优化之读取数据库

下下一期，更重头戏：开发优化之ST05的那些事儿

IOS/ANDROID用户打赏——赞赏码