speed up displaying cl_salv_table

[Former Member]

Hi everyone,

I have really huge table which has to be shown in alv (customer's requirement). I use display method of cl_salv_table class to perform this step. However, it takes too much time to display this table.

Therefore, I ask you if you have any ideas how to speed up performance. I have some ideas. For instance I would like to buffer the alv table and show some results first. Also I had idea to not show whole alv table at once, but print its content into file (pdf) instead. But I could not find any hints in SAP documentation.

How would you deal with such issue?

Any comments, suggestions or answers are very welcome!

Do not hesitate to ask anything.

Regards,

Jozef

[vigneshyeram]

Dear Jozef,

As far as performance is considered we should always avoid CLASS CL_SALV_TABLE, we should always go for Class CL_GUI_ALV_GRID where its method SET_TABLE_FOR_FIRST_DISPLAY or REUSE_ALV_GRID_DISPLAY

If you trace the code or program with SM50, SAT, SE30, ST05 it will show that ALV which is displayed by using Class CL_SALV_TABLE will take more time.
Hope this explanation helps you.

Regards,
Vignesh Yeram

[raymond_giuseppi]

You could also remove the conversion-exit which as used by ALV display, you will have "external view" fields in the internal table and conversion will occur only once during filling of internal table. (The same reason ALV LIST were usually faster than ALV GRID for big data volume)

Else as you wrote you can fill the internal table by parallel process, only refreshing data when one FM send its data back, th first display would be faster, but screen could behave strangely on user point-of-view, especially if the order the records are appended is not the order they are displayed...

But as already written by  Vignesh Yeram  use first a tool like SAT or goold old SE30 to identify where exactly the performance problem is (display, read data, conversion, other routines) for you case.

Regards,

Raymond

[Former Member]

FWIW,

I had 2 date (dats/datum/...) colums; these seem to be particularly slow;

things are faster if I display them as in "non-convert-format" instead (like a numc8)

  (date-conversion/exit thus being avoided)

  (user in this case accepts reading yyyyMMdd format)

  (on other ocassions I used a string, outputting the date e.g. yymmdd or what the user accepts)

  (especially if many columns are empty:

   it seems to me things are faster with strings, which are then simply empty;

   ->thus less memory - instead of 20 bytes for char10(unicode), the size of

   a pointer, I guess - and, nothing to display in the field in the cl_salv_table line;

   if strings can save memory, thus speeding up things (?)

   eg. char40 field ->often only 5..10 chars needed ->string ...

  )

FWIW

I noticed kna1-kunnr:

e.g. a customer 0000123456 is displayed 123456 (hence time wasted conversion/exit)

And similar conversions, which easily go unnoticed.

all in all:

changing types, by creating new data-elements, so that no conversion/exit takes place,

displaying some 100,000 to 500,000 lines in cl_salv_table,

I noticed page-down/page-up is faster.

[Former Member]

Thank you for your comments,

The performance problem is with calling display() method. It takes forever to execute. To be more specific it calls screen 0500 which takes almost 3/4 of time needed for report execution.

Therefore, I do not want to call display() method, but rather save the content of alv into some file or spool. Is it possible?

Raymond, what do you mean when you say "You could also remove the conversion-exit"?

Cheers,

Jozef

[raymond_giuseppi]

If you identify a field with a conversion-exit that can use many cpu (SAT/SE30 sort by net% descending) look for the FM that execute the exit, and if it access a database table, use this database, either

• (many distinct records) with a JOIN in your original SELECT and replace the internal field with conversion exit by a character field without conversion exit in the extracted internal table.The JOIN  should consume less than the exit which will be called at each display of the grid.

SELECT MATERIALD~MATNR_EXT ...
     FROM DBTABLE
     JOIN  MATERIALID ON MATERIALD~MATNR_INT EQ DBTABLE~MATNR.

• (few distinct records) read the table in an internal table and map the original field values from SELECT to external format with READ TABLE (binary search) when filling the final table (displayed)

READ TABLE T_TJ02T ASSIGNING <TJ02T>
   WITH TABLE KEY ISTAT = SELECTED-ISTAT SPRAS = SY-LANGU.
FINAL-TXT04 = <TJ02T>-TXT04.   

Either case, you can keep the original field hidden in a (field catalog) TECH field for usage in following calls.

You need to analyse a little deeper the performance, look for routines called in the display method.

Regards,

Raymond