속도체크

메뉴의 Environment -> Examples -> Perfomance Examples 들어가심 있습니다^^

Loop 문안에서 Loop 를 돌리면 늦어지는것 당연할것같네요.그것보다는 안의 Loop 를 Read 문의으로 해서 binary search를 하시는게 좋을듯 싶네요..

물론 그전에 Read문의 검색조건에 대해서 Sorting을 해줘야 하군요..

LOOP안의 LOOP안에
LOOP AT GLIST WHERE DET_TAKE = 'X'
                              ~
                        AND EBELP = GT_MTSUM-EBELP.

        LV_ZTRQTY = LV_ZTRQTY + GLIST-ZSUCNG.
         ~ .
      ENDLOOP.
가 있을때

아래와 같이
READ TABLE GT_LIST WITH KEY DET_TAKE = 'X'
                                     ~
                        AND EBELP = GT_MTSUM-EBELP.

        LV_ZTRQTY = LV_ZTRQTY + GLIST-ZSUCNG.
         ~ .
 
MODIFY GLIST. CLEAR : GLIST.
쓰면 된다는 말씀이신지요?

네 물론 그전에 where 문 의 검색조건필드에 대해서 sorting해주시고요.

mean님 속도체크를 위해 alv 프로그램을 수정하였는데요..

죄송하지만 메뉴의 Environment -> Examples -> Perfomance Examples의 사용법을 간략히 설명해

주시면 감사드리겠습니다.

read문을 사용할 때 항상 sy-subrc 값을 체크하세요.

subrc가 "0"이 아닌 경우에는 그 밑의 구문을 안타다도록

썬바바님 소트후  read table ~ binary search. 로 바꿨지만 속도는 여전히 늦습니다.

  loop ~

      loop ~

       sort ~

       read table  ~binary search.

현재 형태는 위와 같은데 index를 쓰면 빨라지지 않나요?

소트를 매번 하는것은 좀 그런데요..소트는 최초 바깥루프 돌때 한번만 해주면 됩니다..

그리고 loop~

            loop ~

                 Read이게 아니라..

loop~

  read table~ binary search 를 말씀드린건데.. 좀더 자세한 소스를 보여주세요

아실것 같긴한데 도움이 될까해서 몇자 적습니다.

소트를 한번만 하고 READ ~~ binary search 를 하면 정렬된 상태에서 처음부터 해당값이 나올때까지만 찾고 맞는값을 찾으면 다음은

SEARCH를 하지 않아서 빨라지는겁니다.

위에서 말한것처럼 소트는 LOOP을 드러가기 전에 키로 사용할것을 ITAB테이블 모두 정렬을 한번만 하시면 될겁니다.

그럼 좋은효과 있으시길 바랍니다.

입고시 loop .. loop .. read.. 할 정도의 로직이 필요하지는 않습니다.

이미 중첩 loop를 썻다는 자체가 문제입니다. loop1과 loop2가 특정 필드로 연결이 된다는 말인데

loop1과 loop2에 쓰인 각 itab을 하나로 병합한 후 처리하세요.

그리고, 가능하면 BAPI 쓰세요...