modify table itab from wa Transporting f1 f2 ...
用于指出内表itab 中符合工作区wa关键字的一条纪录的 f1 ,f2 ,...等字段会被wa中的值修改掉。
先看下面的两段程序, 你认为哪一个执行的更快一些?
数据定义和提取:
DATA: BEGIN OF it_marc OCCURS 0,
matnr LIKE marc-matnr,
werks LIKE marc-werks,
dispo LIKE marc-dispo,
plifz LIKE marc-plifz,
END OF it_marc.
select matnr werks
into table it_marc
from marc.
程序一:
LOOP AT it_marc.
it_marc-dispo = 'G00'.
it_marc-plifz = 5.
MODIFY it_marc.
ENDLOOP.
程序二:
LOOP AT it_marc.
it_marc-dispo = 'G00'.
it_marc-plifz = 5.
MODIFY it_marc TRANSPORTING dispo plifz.
ENDLOOP.
两个程序唯一的不同就是MODIFY语句的使用,程序二使用了TRANSPORTING子句,
更新内部表记录时仅更新DISPO,PLIFZ两个字段.
我的直觉是程序二应该运行的快一些,毕竟更新的数据少了.
但是运行结果出乎意料, 10次运行时间如下:
程序一 程序二
122,167 128,485
120,686 128,306
120,732 128,273
120,737 128,273
120,725 128,278
120,418 128,323
120,648 128,267
121,187 128,246
120,741 128,023
120,647 128,012
很明显, 程序一运行要比程序二快, 大概快6%, 具体原因是什么呢? 我实在想不明白.
在SAP关于官方文档中,关于使用TRANSPORTING子句有这样的解释:
With the MODIFY variant "MODIFY itab ... TRANSPORTING f1 f2 ..."
the task of updating a line of an internal table can be accelerated.
The longer the table line is, the larger the speed-up is.
The effect increases for tables with complex structured line types.
从上面的解释来看,内部表的结构越大, 使用TRANSPORTING子句越有效,
于是我修改IT_MARC的定义如下:
DATA: it_marc LIKE TABLE OF marc WITH HEADER LINE.
重新运行, 10次运行时间如下:
程序一 程序二
341,469 311,265
340,983 311,268
341,285 311,432
341,364 311,395
341,630 311,928
341,324 311,358
341,280 311,439
341,328 311,247
341,577 311,269
341,312 311,227
这样的话程序二比程序一更有效率,大概快9%
当然,大多数情况下,我们使用的内部表不会像MARC这样大, 看来有必要寻求一个平衡点.
我做了一下测试,逐步增大内部表的结构,当内部表的大小为150个字节的时候,
程序一和程序二的运行时间基本相等.
其实,对于上面的功能,使用FIELD-SYMBOLS修改的速度最快,速度大概快一倍,
下面是一个示例:
FIELD-SYMBOLS: LIKE LINE OF it_marc.
LOOP AT it_marc ASSIGNING .
-dispo = 'G00'.
-plifz = 5.
ENDLOOP.