Think about potential memory issues with refreshing and many gvars

[ckoerber]

To store correlations, gvars may accumulate over time when refreshing the app or refitting. If the data / priors are particularly large, this may cause memory issues.

We should try to delete caches each time a new fit is executed (and store the initial_fit / generate_fit result) but delete "temporary objects". As far as I can see, starting "fresh" is intended for most of the fits.

I believe, this should be relatively easy to implement with the current architecture but providing a setter method to FitGUI.fit.

@millernb: do you have any suggestions for how to best remove unneeded gvars?

[ckoerber]

Peter addressed a related issue: gplepage/gvar#3 (comment)

As far as I can tell, the "problematic action" is calling process_priors on several iterations (and computing different gvars based on the new prior).

It is generally possible to rebuild a smaller set of needed gvars inside or before/after process_priors using, e.g., gvar.rebuild. However, this might potentially crash due to globally defined gvars which are still used at another point (i.e., ones specified in additional_plots or so).

In short, it seems a bit more complicated than expected and may require having some sort of register of gvars which are used.

It might be possible to simplify this procedure if it is possible to explicitly remove the prior and derived quantities.