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用户打赏——赞赏码

  • 发表于:
  • 原文链接:http://kuaibao.qq.com/s/20180131G07PD700?refer=cp_1026

相关快讯

扫码关注云+社区