It's not so helpful as you think it would be because the heaviest part of the calculation is to create the object respectively the virtual tables behind it. This part is always single-threaded while the agregations would be performed in multi-threading.
In this regard it's important to build a suitable datamodel for your later views. Means to develop the datamodel in the direction of a star-scheme (by really huge datasets it should be even a single table) so that all relevant fields for an object comes from a single table. Within the UI (nested) if-loops, aggr-constructs and interrecord-functions should be as far as possible avoided.
If this basic-work is done you may pick those objects which are further too slow in their responses to investigate if they could be optimized in any way.
Beside this if I look on your screenshot it looked that the expression there is aimed to format results in k, m, b and so on. The added value of such a measure is often limited - therefore you should consider to skip it, especially if there are issues with the performance (probably the real reason for your question). Nevertheless if you want to remain by this logic you could improve the performance by changing the nested if-loop to pick() maybe in this way:
pick(len(floor(YourExpression)), '', '', '', 'k', 'k', 'k', 'm', ...)
- Marcus
.png "Former Employee"){kind=icon}
