itab declaration

[Former Member]

can any one tell me, that itab declration like this can be cause of slow performance?

data: begin of it_address occurs 10.

include structure zvat_vendor.

data:end of it_address.

data : begin of it_address_info occurs 10,

name1 like adrc-name1,

name2 like adrc-name2,

city1 like adrc-city1,

city2 like adrc-city2,

post_code1 like adrc-post_code1,

post_code2 like adrc-post_code2,

street like adrc-street,

house_num1 like adrc-house_num1,

end of it_address_info.

plz guide me.

thanks

Santosini

[Former Member]

hi,

You can declare anyone , it should not be a problem

[Former Member]

Hi,

the performance issues will come at the stage of data flow and usage of nested loop constructs, not making use of buffering of tables, selecting unnecessary fields from the DB tables, not using any indexes which is appropriate for the Select query, and etc., places where typically Performance issues will crop in...

but, while declaring internal tables, no need to worry in which ever the way you define... no performance issues...

Thanks,

Vishnu.

[Former Member]

Hi,

Try out below one,

types :begin of it_address.

include structure zvat_vendor.

types: end of it_address.

data :t_address type standard table of it_address,

g_wa_address like line of t_address.

Donot use occurs if you are not sure as how many records you will be fetching in your internal table.

Here t_address is the internal table and g_wa_address int he header line.

For performance issues , please use minimal select statements, use for all entries or move all entries to the internal table in one stroke .

Please let me know the result.

with regards

Brijesh

[Former Member]

Hello Santosini,

As Brijesh told you before, you should not use the OCCURS clause anymore. It's obsolete. Use instead DATA itab type {Standard | Sort | Hash } table of ...

But the use of obsolete declarations should not cause performance problems. A bad performance is caused by a not well structured SELECT statement.

Have fun,

Heinz

[weltspion]

Hi Santosini,

the kind of declaration costs different amounts of initial memory, but do not affect performance.

Anyway you should use TYPES and TYPE TABLE, as occurs is an obsolete statement.

types: begin of it_address_type 
  include structure zvat_vendor.
types :end of it_address.

types begin of it_address_info_type,
    name1 like adrc-name1,
    name2 like adrc-name2,
    city1 like adrc-city1,
    city2 like adrc-city2,
    post_code1 like adrc-post_code1,
    post_code2 like adrc-post_code2,
    street like adrc-street,
    house_num1 like adrc-house_num1,
end of it_address_info_type

data gt_addr type table of it_address_type. "instead of OCCURS
data gt_addr_info type table of it_address_info_type.

You can speed up the operation of the internal table by using field symbols:

field-symbols <gs_addr> like line of gt_addr.
field-symbols <gs_addr_info> like line of gt_addr_info.

loop at gt_addr assigning <gs_addr>.
 <gs_addr>-city1 = 'Hamburg'.         "no MODIFY needed !
endloop.

This is the fastest way to operate an internal table. Beside this, you can try to sort your data by using sorted or hashed tables. But that has no effect on small amounts of data.

Best regards

Torsten

[Sandra_Rossi]

Santosini, why do you think this particular statement could eventually be a cause of slow performance? (any other statement could be more subject to a bad perf, so why do you ask for this one)

Thx

[Former Member]

Hi Santhoshini,

I would like to tell you that it is not a good practice to write include structure when declaring internal tables, write all the field names.

If possible use types when declaring internal tables ans separate body and workarea.

Thanks,

AMK.

Reward points if useful.