You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This model wasn't written with memory usage at the forefront of its targets, but with the tax-benefit system now written with its complexity, a smaller performance and memory footprint would be hugely beneficial. I can think of one way: finding the subset of variables involved in the net_income computation tree.
The text was updated successfully, but these errors were encountered:
I think so, just investigating the tracer tool in Core which shows the breakdown of computation time for a full run:
Not sure exactly how to interpret this, because some of the variable lengths are due to the order of calculation rather than the cost. For example, because income tax is first calculated to get the Housing Benefit applicable income, its duration appears under housing benefit and then just needs to consult the cache when actually calculating income tax.
This model wasn't written with memory usage at the forefront of its targets, but with the tax-benefit system now written with its complexity, a smaller performance and memory footprint would be hugely beneficial. I can think of one way: finding the subset of variables involved in the
net_income
computation tree.The text was updated successfully, but these errors were encountered: