对于MODIFY itab TRANSPORTING f1 … fn 语句一个有趣的测试

先看下面的两段程序, 你认为哪一个执行的更快一些?

数据定义和提取:
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: <fs> LIKE LINE OF it_marc.
    LOOP AT it_marc ASSIGNING <fs>.
      <fs>-dispo = 'G00'.
      <fs>-plifz = 5.
    ENDLOOP.

One Response

Subscribe to comments with RSS.

  • ai2ming says:

    晕倒了,<fs>这几个字符死活显示不正常,使用HTML格式&lt;fs&gt;也不行.