topic Re: Performance issue - Pricing Report in Application Development and Automation Discussions

Performance issue - Pricing Report

Former Member — Tue, 06 Jan 2009 13:59:46 GMT

Hi Experts,

I have developed an ALV report and I need to improve the performance in production.

I have a relatively complex issue here. I have to fetch data for pricing from a pricing condition from all the respective underlying condition tables (AXXX). Then for every material, I have to display the material class classification characteristics and their values maintained in the material master as well as batch classification characteristics and their corresponding values maintained for every batch.

For example:

In this way, if the condition is having 10 materials, every material has say 10 material class characteristic and 12 batch class characteristics then the total number of rows in the out put should be 130 (one for material and 12 rows for classifications).

How can I optimize the output so that the performance is optimized.

I am also fetching other data for the output like stock and sales order quantity against every material.

I have tried minimizing loops and used select for all entries(I have read a few threads which suggests otherwise). Read statements use binary search. No select * queries.

Warm Regards,

Abdullah

Re: Performance issue - Pricing Report

Former Member — Tue, 06 Jan 2009 14:11:41 GMT

What analysis have you done and what were the results?

Rob

Re: Performance issue - Pricing Report

Former Member — Tue, 06 Jan 2009 14:26:32 GMT

I have tried runtime analysis, and it shows database access slightly higher than system access. But the number of records being fetched in the first query itself is above a quarter million.

Re: Performance issue - Pricing Report

ThomasZloch — Tue, 06 Jan 2009 14:31:02 GMT

I would not sign a lot of the recommendations going around here. Seems like a complex report you are doing there, so here is my personal generic recommendations:

- always use index when selecting from database tables

- avoid redundant database accesses to unbuffered tables, only read fields you really need for processing

- use sorted or hashed tables for reads or loops and access them by key

- use ASSIGNING rather than INTO when reading or looping (small gain)

- use SE30 and if necessary ST05 to fine tune if not yet satisfied with the runtime

Thomas

Re: Performance issue - Pricing Report

Former Member — Tue, 06 Jan 2009 14:37:30 GMT

Thanks everyone. I have tried all that. I am awarding points and closing the thread. I believe the complexity and the number of tables(28 - pricing and master data and classification characteristic related tables) involved and the type of layout required will affect performance.