Two Optimizations

You have to be a child who likes to play the Fortnite game and enjoy it. On top of that, you must have childish negotiating skills to persuade someone older to buy you some V-Bucks (game currency) which makes it  easier to fulfill your game mission.
Play, Explore and Enjoy

Reading Profitability Analysis tables
Table CE4xxxx (xxxx = Operating concern) is the profitability segment level table. CE4xxxx stores each possible combination of characteristic values (as they are posted) and assigns each combination a system-generated profitability segment number. In our system, this is a very large table with millions of records.

If you want a custom report that includes CE4xxxx table values, instead of long runtime loading of complete CE4xxxx Profitability Analysis table into internal one and reading its values, you should use a (possibly large) number of very restricted SELECT statements.

So, we’ve removed the internal table loading:

SELECT paobjnr kokrs prctr kdgrp xblnr wwbu wweba wwpu wwsc konzs
wwcus wwlan wwemu wwpc vkorg vkbur FROM ce4etk1 INTO ce4pom.
APPEND ce4pom.
CONTINUE.
ENDSELECT.

and instead of reading an internal table:

READ TABLE ce4pom WITH KEY paobjnr = vbap-paobjnr kokrs = vbak-kokrs BINARY SEARCH.

we use SELECT statement:

SELECT paobjnr, kokrs, prctr, kdgrp, xblnr, wwbu, wweba, wwpu, wwsc, konzs, wwcus, wwlan, wwemu, wwpc, vkorg, vkbur
FROM ce4etk1
INTO CORRESPONDING FIELDS OF @ce4pom
WHERE paobjnr = @vbap-paobjnr and kokrs = @vbak-kokrs.
ENDSELECT.

The HANA SQL trace indicates that ABAP forwards the prepared statement and that the query execution time is less than 1ms.

In our case, comparing with the previous solution, our daily period report is over 600 times faster (from 60s to 0.09s), and monthly period report is 3.7 times faster (from 76s to 21s).  This solution becomes 15% slower than the old one only on an annual basis.
However, the gain in speed is still great, because the report most often performs for considerably less time periods.

This is a scenario where a secondary index can improve performance – we have a query that selects a very small amount of data from a very large table. In our case, the result is only slightly faster for a one-year interval (7s), so there is no need for a secondary index.

Reading texts
Among other things, our custom developed function module extracts invoice header texts by using READ_TEXT_INLINE. An analysis for a one-year period shows that 35% of the total execution time is spent on fetching texts (8% for the month, 23% for the quarter). For one year’s data this is an additional 189 seconds.
The proposed solution consists of the replacement of READ_TEXT_INLINE used in the loop with the one-time external call of the READ_MULTIPLE_TEXTS which reads multiple texts at once and is optimized to read large amounts of texts with minimal use of SELECT commands. The execution time for a one-year period is shortened from 189s to 3.6s, which is more than 50 times.