Poor performance when scolling in ALV

[ArtiBhat]

Hi Experts,

When i use scollbar in ALV, it takes 2 secs time to navigate.

is there any way to improve the performance other than delta rendering. It's affecting the performance of Application badly as I am using ALV's and the no. of rows extend from 20 to 200.

thanks,

Arti.

[thomas_jung]

How many visible rows do you have? How large is your dataset. The Scrolling mechanism itself is controlled by the framework so there is little you can do to influence it directly. Mostly performance is effected by the number of visible rows.

[ArtiBhat]

Hi Thomas,

The visible row count is 20 and the dataset is of 200 records.

Is there any webdynpro url parameter that will help me in improving the same.

Thanks,

Arti.

[thomas_jung]

With only 20 visible and 200 records on the backend, the scroll should be really fast. Have you done a performance trace on the client side to see where the time is being spent (possibly a long runtime in a validation or wddomodifyview)? If you change back from the scroll to the table paginator, is the runtime also long?

[Former Member]

Hi Arti,

You should do a performance check by pressing ctrlshiftAlt+P and see how much time and memory is being used by application server and client rendering time on a request of these data from the table.

Ideally web dynpro can easily handle around 10 lac entries.

Regards

Ajay

[ArtiBhat]

Hi Ajay,

I would request you to explain elaborately how I can do the performance check.

Thanks,

Arti.

[thomas_jung]

If you are NetWeaver 7.01 you can use the key combination within the browser ctrlshiftAlt+P as already suggested. This will give you the performance breakdown by client side rendering, server side processing, and total time. However if the time is being spent on the server side, I would suggest using the ABAP performance tools for a more comprehensive look at where you time is being spent. You can reuse all the existing ABAP performance tools within Web Dynpro ABAP. From transaction SICF, choose the service node for your WD application. Then from the menu choose Edit->Runtime Analysis->Activate. This allows you to configure the filters for your runtime analysis.

[Former Member]

Hi Thomas,

After I run the application, Im using this key combination but where to check for the results.

Can you provide me with any links.

In my application also, there is a poor performance. My visible rows are 100 or may exceed them. But i have around 40 columns . While scrolling, the performace is very low.

Regards,

Lekha.

[thomas_jung]

>After I run the application, Im using this key combination but where to check for the results.

Can you provide me with any links.

Just run transaction SE30 or the newer version in transactoin SAT. This lets you analyse existing Runtime traces.

>In my application also, there is a poor performance. My visible rows are 100 or may exceed them. But i have around 40 columns . While scrolling, the performace is very low.

I thought you said ealier that your number of visible rows were low. Now you state that you have 100 or more visible rows. The number of visible rows greatly impacts performance. Consider a much lower number of visible rows and allow the scrolling to occur within the ALV. Also consider not having all 40 columns visible. Use the SET_SCROLLABLE_COL_COUNT method of the ALV Model class to control the number of visible columns. You then get a horizontal scrollbar:

l_table->if_salv_wd_table_settings~set_scrollable_col_count( 8 ).

[Former Member]

Hi Arti,

When you press CTRLALTSHIFT+P in the browser a small window pan will come in the top right of the explorer.

You have options for memory, performance measurement.

I have attached a screenshot please have a look.

[Screenshot for performance check|http://irishchants.com/SAP/performance.JPG]

Take Care

Ajay

[thomas_jung]

You should note however that the CTRLALTSHIFT+P is only in NetWeaver 7.0 Enhancement Package 1 and higher. Base 7.0 systems do not have this option. Also you must be running with Lightspeed rendering enabled.

[ArtiBhat]

Hi All,

I noticed that poor performance is caused by wddomodifyview as i haev many methods inside it which are called when I scroll in ALV. Now i think I can stop wddomodifyview from calling all these methods if i get to know the event for table scoll.

I would request you to let me know which place the event is triggered and how can i use this in my wddomodifyview.

Thanks,

Arti.

[Former Member]

Hi Thomas,

I already have used the SET_SCROLLCOUNT method with value 3. My total visible columns are 10 this is to avoid the scrollbar on the page and fixed columns are 7.

so that i get only the scrollbar for the ALV not for page.

This is because we have deployed the application in portal which inturn is a WDA, that has one more scrollbar control.

While scrolling accross other 30 columns is taking time.

Any inputs.

Regards,

Lekha.

[thomas_jung]

I'm confused. We have Lekha and Arti Bhat both describing problems with applications in this thread. Are you both working on the same application?

>I noticed that poor performance is caused by wddomodifyview

I think we need examine what you are doing in WDDOMODIFYVIEW then. WDDOMODIFYVIEW should be a method of last resort to create dynamically generated UI elements. Over it is abused by beginners, but should rarely be used. The method fires for every server event. You can't necessarily determine the event type within the method. Your logic in WDDOMODIFYVIEW should be designed to work independent of the event and only trigger dynamic changes in the UI when necessary.

What are you doing in WDDOMODIFYVIEW and what control structure do you have around this logic?

[ArtiBhat]

Hi Thomas,

I am using this method to set the edtability of ui elements within ALV cells and also setting visibility amd editability of other Ui elements on the ALV. This thread is initiated by me and I am not working together with Lekha .

Thanks,

Arti.

[thomas_jung]

>

> Hi Thomas,
> 
> 
> I am using this method to set the edtability of ui elements within ALV cells and also setting visibility amd editability of other Ui elements on the ALV. This thread is initiated by me and I am not working together with Lekha .
> 
> Thanks,
> Arti.

WDDOMODIFYVIEW is not the correct location for such manipulation of the ALV. It comes at a great cost as you can see. You should perform this logic once when you initialize the ALV (perhaps in the WDDOINIT) and then only trigger the logic again when you need to make changes. It is quite wasteful to have this logic in WDDOMODIFYVIEW and it is not necessary. You can call changes via the ALV Model API outside of the WDDOMODIFYVIEW just fine.

[thomas_jung]

Lekha, please do not hijack other people's threads. You are quite adding to the confusion by talking about a completely different application within this thread. It is not fair to the original poster or those trying to help them. If you have a question, create your own thread.

[Former Member]

Hi Thomas,

Ok sure, i will open the other thread. I was replying to this as I'm experiencing the same problem.

Regards,

Lekha.