cancel
Showing results for 
Search instead for 
Did you mean: 

Performance issue on ALV SALV_WD_TABLE

Former Member
0 Kudos

Dear All,

Recently I meet a problem on our webdynpro report performnace issue. As in the development, we use SALV_WD_TABLE to design a ALV. and verything work correctly in our DEV system.

But after when our QAS system, there are more records for the ALV, one of them has 21000 records. And in the layout, we have a column as checkbox.

If we click any one checkbox, then the layout will respond almost 1~2 minutes. With debug I found the most time cost in the standard program.


And I also define a hierarchy column, and with default all nodes are folded. and there is a button to expand all nodes.

But after click button to expend, it will really slow. for the folded records is 2000 rows.



If any solution I can use to optimize those performance issue?

Many thanks for your help!

BR

Vincent Chen



Accepted Solutions (0)

Answers (2)

Answers (2)

adam_krawczyk1
Contributor
0 Kudos

Hi Vincent,

I am experiencing similar table performance problems, in NWBC client however. I am not sure if this will be related to SALV_WD_TABLE but I guess so, please try.

Can you try to set the property of table visibleRowCount to low value like 20 for example? This should enable scroll bar on the table level and at one time only currently visible rows will be rendered by the browser, not the full content.

In my example I found out that it is just the rendering of table which depends on how many rows and columns are loaded to the browser client. When I set the limit to 15 for example I see in SAT logs:

- 15 times call for Call M. {O:2830*CL_TABLE_ROW}->IF_NW7_VIEW_ELEMENT_ADAPTER~SET_CONTENT

- 300 times call for Call M. {O:2836*CL_TABLE_DATA_CELL}->IF_NW7_VIEW_ELEMENT_ADAPTER~SET_CONTENT

- 210 times call for Call M. {O:2851*CL_INPUT_FIELD}->IF_NW7_VIEW_ELEMENT_ADAPTER~SET_CONTENT

Numbers explanation:

- maximum 15 rows are visible on the screen due to visibleRowCount set to 15 value

- table has 20 columns, so there are 20 x 15 = 300 data cells for rendering

- 210 - only some columns are editable so probably this is something related (14 x 15 = 210).

If I set the limit visibleRowCount to 100 for example, all these numbers above increase proportionally form 15 to 100, from 300 to 2000 etc. Rendering of cells of course takes much more time then.

The difference is also in functionality - for visibleRowCount all rows are read to browser memory so it is fast scrolling from browser. For limit 15 however, only 15 rows are shown and the scroll bar comes from ALV, causing refresh on each scrolling up or down (which causes some delay).

In addition on ROOTUIELEMENTCONTAINER I have set property Scrolling to None.

Regards,

Adam

former_member197475
Active Contributor
0 Kudos

Hi Vincent,

Please check on the below points for your performance issues.

1. Make sure that your ALV context design should be very simple. A large number of context nodes/attributes definitely kills your application performance.

2. Check whether do you handled your business logic in WDDOMODIFYVIEW method. This may also cause some low performance issue.

3. Try to use different browser and check which is good in performance, as browser performance depends on rendering the java scripts. You can see the below e-class tutorial.

4. Also you can try for Delta rendering for WDA.

Delta Rendering - Web Dynpro for ABAP - SAP Library

5. Are you handling some huge logic on your check box action???

First try for the above options. Lets see now:)

BR,

RAM.

Former Member
0 Kudos

Dear RAM,

Thanks for your feedback.

1. in our context, there are almost 30 attributes. Is it the reason for the bad performance when large vloumn records?

2. Nothing in WDDOMODIFYVIEW.

3. We used the NWBC 4.0 to run the WDA application.

4. I have implement the delta configuration. But it seems does not provided any improve.

in fact there is only one view in our development the ALV view. Not comlex layout.

  

5. check box, just has every short logic to excute.'

By the now the main issue on large vloumn records, if low records, all working fast.

Now our records should be more or less 22000 recors, even with collapse hierarchy also has 2200 records.

So when we typing any one hierarchy node to expand, it will cause almost 47 seconds delay.

click the check box, almost 2-3 seconds delay.

Do you still have any other idea we can add to improve the performance.

Many thanks for your help!

BR
Vincent Chen

ramakrishnappa
Active Contributor
0 Kudos

Hi Vincent,

As there are many records are being displayed in alv and every action would trigger roundtrip of process of rendering.

Here I would suggest you the below points

Design:

  • By any chance, is any Database query on any action ? If so move that out of action and push into assistance class. Get data into temporary tables and use whenever required
  • Need to check the hierarchy building logic : On every expand/collapse, the nodes are being constructed and finally rendering triggers. Its huge task to reconstruct whole hierarchy and render back. I think this cannot be avoided as its the design.
  • On check box action: I suggest try to remove the logic from this action and if possible remove the event trigger on check box, So that no further rendering on every click happens.

Data:

If not much improvement from above design restructuring, I suggest to break up the data into smaller packets. Provide user to view option of viewing 1-500, 500-1000, so on. So that only those number of records being picked and shown in the alv.

Regards,

Rama

Former Member
0 Kudos

Hi Rama,

Thanks for your feedback.

Provide user to view option of viewing 1-500, 500-1000, seems possible.

But it is difficult to implement in my development.As we still have hierarchy node, it is too difficult to caclulate the avaiable rows.


Thanks for your help!


BR

Vincent Chen