In general you could calculate everything within the script. But to calculate your mentioned expression means to create an aggregation-load against a dimensional context (the fields within the group by statement) which is quite slow in Qlik and produced always a more or less static result. Usually it's as a regular measure not very suitable because it would needed to be repeated multiple times ... one for each dimensional context which should be displayable.
Nevertheless by one or two quite heavy calculations it may be sensible to transfer them within the script. Beside the direct calculation of measures within the script it might be useful to reduce the total amount of records by changing the granularity of the data within your fact-table, for example by keeping the data from the current year on a transactional level, aggregating the previous year on a daily level and the older data are aggregated to a monthly level. In many usecases it won't lead to real lost of information because nobody from the business looked at transactional data if they were years ago.
Further your used star-scheme is considered as the best compromise in regard to load- and UI-performance, app-size, development efforts and clarity in the datamodel - but by very large datasets you may get a better UI performance with a big flat-table. Just give it a try.
Another way to keep an application performant is to restrict the max. size of rows and columns which an object could display - nobody could really handle tables with dozens of columns and many thousands or even millions of rows (beside the efforts to calculate the values for it it will also need quite a lot of ressources to render the object).
Further thoughts to reduce the size of the application is to look on the cardinality of the fields - means how many distinct values are there. A very common example for this are timestamps which might be better splitted into a date- and a time-field. Also the removing from formattings could save a a lot of memory - those formattings could be set within the document/object-properties.
Beside this the calculations itself might be optimized if some of the conditions could be already checked and flagged within the script so that your expression didn't look like:
sum({<a few conditions>} something)
else
sum({<a single condition>} something)
or maybe
sum(something * flag) // whereby flag is 0 or 1
- Marcus
