I think what do you want to do isn't possible - at least not with your approach. To store any results from UI calculations you will need to use actions/macros but without a new reload you couldn't use them within the application (unless you store within a source which you could access with direct discovery).
IMO much too complicated especially as it didn't cover you real issues which is quite likely an unsuitable datamodel. Nearly always when UI calculations are too slow it's caused from the datamodel. From your example I deduce that at least fields from 5 different tables are involved (depending on the dimensionality within the target-objects and further selections it may even more). If those fields aren't well associated it could become quite hard to get the expected results and/or the performance is often rather slow.
Therefore I suggest to rethink the datamodel and to develop it in the direction of a star-scheme and checking if there are more possibilities to optimize it - from a performance point of view but also logically, for example checking for NULL's in certain fields replacing them with real values. This means to work on the causes and not on the impacts.