1. 這兩個IF ELSE分支裏檢測的條件其實邏輯上來講都是同一類，應該合併到一個IF分支裏進行檢查：數據庫
It is an expensive operation to open a file in application server with 50MB file size.編程
Current logic is:併發
1. Open the file in application serverapp
2. Read the file content line by lineless
3. If the file is regarding IPG or MIDH or TPG, handle with each line separately函數
The correct logic should be:oop
1. Check the file path whether it is IPG or MIDH or TPG related. If not, quit the report.性能
2. Handle with each line directly without evaluate file path in the BIG loop.fetch
The validation logic for input records should be improved
Loop at all service BOM, check whether the ID in current loop does exist in validation table lt_valid_prod or lt_valid_sp. If so, delete them via DELETE TABLE XXX FROM <current line>.ui
Improvement: use DELETE XXX WHERE product_id NOT IN <range table>. It is more efficient when lt_srv_bom_file has a huge number of records. See comparison below ( unit: second )
這是一個性能問題。使用ABAP原生支持的NOT IN關鍵字能夠得到更好的性能。性能評測以下：
Avoid using SELECT to access table with a large number of entries
In product / IObject area, the best practice is to use OPEN CURSOR / FETCH NEXT CURSOR to access big DB table.
若是須要用ABAP OPEN SQL讀取一張包含海量記錄的數據庫表，那麼推薦使用OPEN CURSOR進行分塊讀取。
Although this solution will spend almost the same time to fetch the data from DB, it has far less memory consumption compared with using SELECT to fetch ALL data from DB at one time.
The original dump due to out of memory issue could be eliminated by replace SELECT with OPEN CURSOR statement.
這種方式和直接用SELECT相比，能顯著減小內存消耗量。
使用併發編程提升應用程序場景
經過下面這段代碼模擬一個費時的ABAP程序：
定義一個ABAP函數：
這個函數裏執行一大堆計算，而後把傳入的product ID寫到一張自定義表ZJERRY1裏。
調用這個函數的代碼：
注意第二種方案使用STARTING NEW TASK達到的併發執行效果：
經過比較，第二種解決方案的效率是第一種的四倍。
1. The more CPU & DB time spent in ZINSERT, the better performance will be gained by using
parallel processing (Asynchronous RFC call).
2. The more number of ZINSERT call, the better performance will be gained by using parallel
processing.
要獲取更多Jerry的原創文章，請關注公衆號"汪子熙":