Internal table - fill and read: do-it-yourself

harry_dietz · ‎01-12-2006

Continuing...

First part was about the idea behind this trilogy, what and how I could or should measure, last part on the chart engine and this part will contain the "rest" of the code. I show a lot of macros. But don't be angry with me - all macros are small, really readable and help to shorten the code a lot. (I swear that I never use macros in normal development.)

To Do List

Now let's see what's to do...

Create structures and internal tables
Create helpers for the measurement
Create table fill routine
Create table read routine
Put the measurement data in chart engine and ALV grid

Create structures and internal tables

What I want to measure (and you can easily extend this) are a) standard, sorted, hashed tables and b) short, medium and long structures. So I created three structures like this:

BEGIN OF local_short,

key1 TYPE char10,

key2 TYPE char10,

data1 TYPE char10,

data2 TYPE char10,

data3 TYPE i,

data4 TYPE sydatum,

data5 TYPE numc10,

END OF local_short.

This is the short structure, the medium and the long structures look similar with more fields like data1..5.
To measure the different fill-methods -- append and a sort at the end, insert with binary search, insert into sorted table (unique and non-unique), insert into hashed table -- I need these tables:

lt_short_apsort TYPE STANDARD TABLE OF local_short,

lt_short_binary TYPE STANDARD TABLE OF local_short,

lt_short_sort_u TYPE SORTED TABLE OF local_short WITH UNIQUE KEY key1 key2,

lt_short_sort_n TYPE SORTED TABLE OF local_short WITH NON-UNIQUE KEY key1 key2,

lt_short_hash_u TYPE HASHED TABLE OF local_short WITH UNIQUE KEY key1 key2,

And I need these tables as medium and long, too.

For the ALV grid I did it the simple way: create a structure with columns for each possible measurement. So one column for "short structure hashed table fill", one for "short structure hashed table read", etc. And because I wanted to see how optimized (with table key) read and non-optimized read behave, I have two columns for each table read kind. This sums up to 3 (short/medium/long) * 5 (append+sort/binary/sorted-unique/sorted-non-uniqe/hashed) * 2 (std.read/opt.read) = 30 columns. Adding the 3 * 5 = 15 fill-table columns this gives 45 columns. Then I have a column for the number of the "run", because I want to have several runs to fill/read a table; one column for the number of appends or inserts and one column for the number of table lines (this may differ to the number of insert/appends, because of identical keys). So the first part of the ALV grid table structure looks like

loopindex TYPE i, " # of run

iterations TYPE i, " # of tried append/inserts

tablelines TYPE i, " # of lines in table

fill_apsort_short TYPE i, " these are the runtimes

fill_binary_short TYPE i,

fill_sort_n_short TYPE i,

fill_sort_u_short TYPE i,

fill_hash_u_short TYPE i, etc...

Create helpers for the measurement

To do the measurement I have two small macros with "start/continue" and "stop" of a measurement. The macros look like

DEFINE runtime_start.

get run time field lv_runtime_start.

END-OF-DEFINITION.

DEFINE runtime_end.

get run time field lv_runtime_end.

ls_time-runtime = ls_time-runtime + lv_runtime_end - lv_runtime_start.

END-OF-DEFINITION.

And in ls_time you find a structure which contains the current measurement info like # of run, # of tried append/insert, # table lines, the name of the measurement like "fill_binary_short" and of course the runtime 'until now'. So at first I set ls_time-time to zero and then the three things

call runtime_start
do what is to be measured
call runtime_end

can be done until everything is finished for one run.
Afterwards I optionally compute the runtime per iteration, so the growing tables effect can be seen. There is a small macro

DEFINE compute_perline.

if perline = 'X'.

ls_time-runtime = ls_time-runtime * 100 / ls_time-iterations.

endif.

END-OF-DEFINITION.

Each time a measurement (one run of n reads or one run of n insert/appends) is done, a ls_time is appended to an internal table. And +collect+ed in a second table. Later on this +collect+ed table will be converted to XML for the chart engine and into the ALV grid structure table.

Create table fill routine

To ensure we have no influence from the creation of the table lines, I decided to first create a "template" table - a table containing all the entries which are to be inserted. Also I want to control the number of keys to be created... So I create a basis table and in the table fill routine I loop on this table and do this (this is implemented in a macro called 'get_line'):

read basis table first line
copy line content to internal table ITAB
move first line of basis table to the end

(ITAB is the table I want to measure)

The table fill routine has two versions, one where only the insert/append (and in the standard+sort method the additional sort) is measured and one where the complete process is measured (including copy, looping, etc.):

table fill with everything in measurement
2. runtime_start
4. do iterations times
6. get_line
8. find index to be inserted (only in read binary case)
10. insert into ITAB
12. enddo
14. sort ITAB (only in case of the append+sort)
16. runtime_end
table fill with only the insert/append in measurement
2. do iterations times
4. get_line
6. runtime_start
8. find index to be inserted (only in read binary case)
10. insert into ITAB
12. runtime_end
14. enddo
16. runtime_start
18. sort ITAB (only in case of the append+sort)
20. runtime_end

(There are 5 macros for each case (append+sort, read binary, sorted non-unique, sorted unique, hashed) which includes both versions)

Create table read routine

The table read has also two versions where in the first case the complete loop is measured and in the second case only the read is measured. Again I use the basis table to have a fixed list of keys to be accessed (the basis table is created in a random order before the table fill is done).

table read with everything in measurement
2. runtime_start
4. do iterations times
6. get_line
8. read table ITAB
10. change_found
12. enddo
14. runtime_end
table read with only the read-table in measurement
2. do iterations times
4. get_line
6. runtime_start
8. read table ITAB
10. runtime_end
12. change_found
14. enddo
You can see here an entry 'change_found': this is a macro accessing the read table and modifying it. I heard of some optimizations in internal table handling in case the table is not modified...therefore I inserted this.

(There are 5 macros as in the table fill measurement, but additionally I have one macro where the table read is a standard read: no read binary, no read with table key; this macro is used for each of the table types.)

Put the measurement data in chart engine and ALV grid

The measurement data now finally are two tables with the columns

(only in the detailed data) "loopindex" which contains the index of the run (fix, ranging from 1 to 10)
"groupname" which contains the name of the measurement (read_short_hashed)
"runtime" which contains the overall or per line runtime
"size" which contains the number of tried insert/appends

The detailed data (internal table lt_time) is shown in the ALV grid and the aggregated data (internal table lt_meantime) is shown in the graphics.

The ALV grid is filled via "ASSIGN COMPONENT" because the "groupname" is identical to the name of the column in the ALV grid structure. The chart engine is filled as shown in the last blog.

It should also be easy to use the GRAPH_3D (as proposed by Sharad Agrawal) instead of the chart engine, because the structure is simple and the examples for GRAPH_3D are nice and this is also available before 6.40

The coding and what else is to do

So now ...

Copy and paste the content of the textbox at the end in a report
Create a screen '0100'.
Go to the screen flow logic and un-comment the modules so they are STATUS_0100 and USER_COMMAND_0100
Add as ok-code 'OKCODE' and add a custom container (resizable and BIG) named 'CC0'
In the GUI status set some button to 'EXIT'
Give the selection parameters their texts:
In case I didn't forget anything: run...

The measurement results

All times are done with the report above and use the runtime divided by the number of reads or by the number of tried insert/appends.

My machine is a Linux 64 bit machine with Netweaver 2004s and it shows for the table fill