Is it applicable to convert Aging Report into RAP ?

[Sadory]

Hello everyone, I need your advice.

I've been requested to create a program for againg raw materials which are assigned over all plants and storage locations for each 10 days over 365 days, beside finding out the on-hand quantity and future remaind raw material delivaries.

My Team leader gave me similar old program for same purpose, but it wasn't optimized at all because of the following reasons: 
1- Over-fetch for un-necessary data.
2- Using standard table type instead of sorted table type.
3- Calling SELECT query inside loops.
4- Hits Database many times becasue of many SELECT query instead of using Joins.
so the program displays the list output after ~ 10 mins as average ( list volumn can hit 60K row ).

In the program each raw material is checked if it's existed between 2 dates, for example between today and last 10 days, if there's quantity so I increase the amount in the column for this date period, and so on periods until more 365 days.

 After dealing with the above points, I've been able to reduce the running time to ~ 5 mins, which is better but not enough for me ! 

My Question is : If this report is converted into or made by ABAP RAP with all same report features and manipulation,  can i have better performance ? if no, What should I do more for better performance because 5 mins is not sufficient for me? 

[TMNielsen]

Even if I'm not yet a RAP expert I think it is right to say that the database selections and the looping on internal tables will be very similar in RAP compared to classic abap, so  a transition to RAP will not improve performance.

It is not clear what is meant when you say "each raw material is checked if it's existed between 2 dates". I expect it involves select from mbew, mkpf and mseg and that can be a heavy job.

If you are in an on-premise environment with SAP GUI you can performe a runtime analysis (transaction SAT) to see which parts of the program costs most time?

As this is based on historical data that will not change, you may attach the problem with a different approach.

For example:
Make a version of the program that calculates the result not for current month, but for the previous 11 month and save the result in a database table. Run this program in a nightly background job.
Make a version off the program that only runs with the current month data and then combine it with the saved result for the previous 11 months. This would then the program the users run in foreground.

Best Regards
Thomas Madsen Nielsen