sorted table and standard table

[Former Member]

Hello everyone,

The following is my code:

< "

loop at wt_data into wa_data where send_sc is not initial and send_fin is not initial.

  read table it_int into wa_int with key begda1 = wa_data-send_sc  endda1 = wa_data-send_fin.

    if sy-subrc eq 0.

      wt_tabix = sy-tabix.

      loop at it_int assigning <fs> from wt_tabix.

        if not ( <fs>-begda1 = wa_data-send_sc  and  <fs>-endda1 = wa_data-send_fin ).

          exit.

        else.

          <fs>-interval = wa_itbl-interval_no.

          <fs>-month    = wa_itbl-month.

          <fs>-diff     = wf_diff_date .

          <fs>-year     = wa_data-send_fin(4).

          <fs>-interval_r = wa_itbl-interval.

        endif.

      endloop.

    endif.

enloop.

">

so i have declared wt_data as standard table and it_int as sorted table.

but i think the same operation can be carried out using it_int as a standard table. isn't it? then why it is said that using index on sorted internal table increases your performance,,,,,

and second.. if data is unique so can i use hashed table ..if so..can anyone put some dos and don'ts of hashed table .

I am looking for a better performance...in live system the program deals with nearly millions of records.

[Former Member]

Hello everyone,

The following is my code:

< "

loop at wt_data into wa_data where send_sc is not initial and send_fin is not initial.

  read table it_int into wa_int with key begda1 = wa_data-send_sc  endda1 = wa_data-send_fin.

    if sy-subrc eq 0.

      wt_tabix = sy-tabix.

      loop at it_int assigning <fs> from wt_tabix.

        if not ( <fs>-begda1 = wa_data-send_sc  and  <fs>-endda1 = wa_data-send_fin ).

          exit.

        else.

          <fs>-interval = wa_itbl-interval_no.

          <fs>-month    = wa_itbl-month.

          <fs>-diff     = wf_diff_date .

          <fs>-year     = wa_data-send_fin(4).

          <fs>-interval_r = wa_itbl-interval.

        endif.

      endloop.

    endif.

enloop.

">

so i have declared wt_data as standard table and it_int as sorted table.

but i think the same operation can be carried out using it_int as a standard table. isn't it? then why it is said that using index on sorted internal table increases your performance,,,,,

and second.. if data is unique so can i use hashed table ..if so..can anyone put some dos and don'ts of hashed table .

I am looking for a better performance...in live system the program deals with nearly millions of records.

[former_member209920]

Hi Prabhakaran,

Your first question is when same opeartion can be done using standard table then why use sortd table.

But you yourself have given answer. Performance is the reason for using sorted tbale when we are reading using index.

Hashed Table :

*  Should have unique key.

*  Preferred when insertion or deletion in internal table is very low and only read operation is major activity.

*  Number of entires should not be more than 2 million (not confirmed but dump may occur).

For better performnace, try to reduce iteration of loops. Also, use parallel cursor when you need loop inside a loop. Along with LOOP.... 'FROM' also provide 'TO'.

Surf thru INTERNAL TABLE TYPES

Regards,

ManuB

[Former Member]

Hello Manu,

My question was  actially how the sorted table give better performance using index....

lets say i use the standard table using index...in  Loop AT statement i specify the index. htat is FROM ..then the difference???

[former_member209920]

Hello Prabhakaran,

To answer this, first I want to tell that in case of standard table, it traverse linearily( where search time is of order n ).

i.e. if index is suppose 101, it will match the index of each line one by one and when it will reach to 101, search will end .

While in case of sorted table, it use Binary Serach Technique ( where search time is of order (log n) ).

Other than this reason, selecting a type of internal tbale depends on the number of operations to be performed on the internal table i.e. insertions, deletions, modifications, number of 'READ TABLE' instances, number of 'LOOP AT' instance, uniqueness of records and most importantly number of records.

Regards,

ManuB

[Phillip_Morgan]

hello,

If it can help, check here. At the bottom there is a section on "choosing a table type".

[Former Member]

like Mr.Manu has said avoid using loop inside a loop and in case you need to use it then follow parallel cursor method. where the loop only starts from the index where the first data is read using read table and hence the loop will not run again through all values for each data that is fetched.

an eg of parallel cursor that I have used in my program.

READ TABLE lt_infty_at INTO lx_infty_at
                            WITH KEY begda = lx_overview-curdat
                            BINARY SEARCH.
     IF sy-subrc = 0.
       lv_index = sy-tabix.
       LOOP AT lt_infty_at INTO lx_infty_at FROM lv_index.
         IF lx_infty_at-begda <> lx_overview-curdat.
           EXIT.
         ENDIF.
         lx_overview-infty  = lx_infty_at-infty.
         lx_overview-subty  = lx_infty_at-subty.
         lx_overview-endda  = lx_infty_at-endda.
         lx_overview-begda  = lx_infty_at-begda.
         lx_overview-beguz  = lx_infty_at-beguz.
         lx_overview-enduz  = lx_infty_at-enduz.
         lx_overview-hat01  = lx_infty_at-stdaz.
         lx_overview-hrc01 = lx_overview-hab01 + lx_overview-hat01.
         lx_overview-hrm01 = lx_overview-hpl01 - lx_overview-hrc01.
         CALL FUNCTION 'HR_GET_SUBTYPE_TEXT'
           EXPORTING
             infty = lx_overview-infty
             subty = lx_overview-subty
           IMPORTING
             stext = lx_overview-atext.
         IF sy-subrc <> 0.
* Implement suitable error handling here
         ENDIF.

         APPEND lx_overview TO e_overview.
         CLEAR: lx_overview-atext,
                lx_overview-hat01,
                lx_overview-hrc01,
                lx_overview-hrm01.
       ENDLOOP.
     ENDIF.

You can also use standard table but you will need to sort the internal table after fetching the data into it and then write BINARY SEARCH at the end of the read table statement. By declaring the table as SORTED table this is all done automatically..

[Former Member]

this is not what is usually called parallel cursor/index! This is just the work-around to get optimized loops on standard tables.

If you are allowed to change the table type, then use SORTED TABLE, which does the same but is much simpler.

[naveen_inuganti2]

Hi Prabhu,

Two points...

• When reading data from internal tables using READ TABLE, the BINARY SEARCH addition should always be used in conjunction with tables defined as TYPE SORTED.  Be sure to specify either a UNIQUE or NON-UNIQUE key with tables of TYPE SORTED.  TYPE STANDARD can also be used, but data must be appropriately sorted prior to using the BINARY SEARCH addition.  Note that TYPE SORTED should not be used for internal tables that need to be sorted different ways within the program.  In this case, use TYPE STANDARD in combination with the SORT statement.  If you have to re-sort a table many times, it may be better to create multiple TYPE SORTED tables with the different KEYs then perform many sorts.

• Use SORTED table types with LOOP … ENDLOOP.  It appears that SORTED tables have an advantage over STANDARD tables that are manually sorted when iterating over the table contents.  Ensure that the fields you specify for the SORTED table type are the same that are used in the WHERE clause in the LOOP … ENDLOOP.  When doing this, it appears that the ABAP processor can “short-circuit” the LOOP and stop reading the table when it reaches the end of matching values for the first field.  In the below example, the ABAP processor should only need to read n+1 records where n = number of records where field2 = value1.

DATA: sortedtable TYPE SORTED TABLE OF type WITH NON-UNIQUEY KEY field2 field8.

LOOP AT sortedtable ASSIGNING <field-symbol> WHERE field2 = value1 AND field8= value2.

Regards,

Naveen Inuganti

[SuhaSaha]

Naveen Inuganti wrote:
When reading data from internal tables using READ TABLE, the BINARY SEARCH addition should always be used in conjunction with tables defined as TYPE SORTED. ...

Hello Naveen,

Not sure what you mean by this statement.

But the use of the addition BINARY SEARCH for READ TABLE statement on SORTED TABLEs is redundant. As the records are READ using binary search algorithm if the search key contains the table key or a left-justified part of it.

BR,

Suhas

[Former Member]

Please note, the BINARY SEARCH is unnecessary with SORTED TABLES, it is allowed to simplify the switch from standard to sorted tables without need to change all READs.

[Former Member]

Hello,

Thank you everyone for your valuable points.