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: <fs> LIKE LINE OF it_marc.
LOOP AT it_marc ASSIGNING <fs>.
<fs>-dispo = 'G00'.
<fs>-plifz = 5.
ENDLOOP.