Sent: Friday, 29 January, 2016 8:17 PM

Attachment 的metadata里定義的data type和runtime時的data type不一樣

Metadata里是這個structure：

Runtime變成了這個：

這些BPID和file_size 是runtime 生成的？這個structure里header_guid也沒了。

Attachment和其他四個節點不太一樣。

當用新的service url訪問時，https://lag3:44354/sap/opu/odata/sap/CRM_ODATA/TaskCollection

動態生成的structure是BP 定義的common structure，如下：

用老的service url：https://ldag3:44354/sap/opu/odata/sap/CRM_TASK/Tasks?$filter

則動態生成的structure是我們task自己的attachment structure。

優化后的代碼需要能夠同時handle 這兩種情況。有兩種辦法。

方法1：如果line 15 ASSIGN失敗，說明當前的internal table類型是BP定義的。

其實就是通過line 17設置的標志位，如果是BP的structure，就用BP的field symbol接，否則用task 的field symbol接。

這種方法好處是速度比較快，因為只有1處泛型處理。缺點是在代碼里出現了BP的structure crmt_bp_odata_attachment_t.

方法2：這種辦法從直接上能發現不需要引入對BP structure的依賴，代碼里只需要我們自己的attachment structure。

a. 在line 10~11 動態assign一個field symbol

b. 其目的是line 23用來接真實的attachment數據，然后line 24寫回到result container里去。
注意這里line 24的兩個field symbol都是完全generic的，而且賦值在LOOP里完成，所以方法2的泛型處理次數為 1 + task個數。

所有高級語言的guideline都說盡量避免泛型處理，除非沒其他辦法。那這兩種辦法性能有多少差異？因為Zclass里attachment 都是hard code的，所以比較的性能差異其實就是泛型處理的overhead。

當處理10個task時，相差300微秒

100個task：方法1就比方法2快1倍了

500個task：

1000個task：

1萬個task：

這時差距就甩開了，方法2所有操作都是在memory里做的，居然也消耗了0.2秒。

鑒于我們offline的use case，1千個task都算相當大的數據量了，這種情況下方法2消耗的絕對時間仍然不大，所以最后我決定采用方法2.
要獲取更多Jerry的原創文章，請關注公眾號"汪子熙":

總結

以上是生活随笔為你收集整理的ABAP 泛型处理的overhead - generic programming的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。