Improve memory usage of MetaLearnerGridSearch

[FrancescMartiEscofetQC]

The idea of this PR is to improve the memory usage of MetaLearnerGridSearch. The main issue was that all metalearners instances were saved in memory. Each of this was referenced in two places, the jobs list and the raw_results_ list.

• To remove it from the jobs list now _FitAndScoreJob stores only the factory and the parameters, then the MetaLearner object is created inside the joblib job which runs _fit_and_score.
• For the reference in the raw_results_ now one can choose to return a generator from joblib.parallel instead of materializing all the results in a list.

It is important to notice that if the user wants to iterate themselves over the results and not materialize them (for example, to compute policy values and only store the one with the highest policy) then store_results and store_raw_results must be set to False as if store_results is True then the generator would be consumed when calling _format_results.

It also adds a grid_size_ attribute which can be useful if a generator is returned.

Checklist

• Added a CHANGELOG.rst entry

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 94.88%. Comparing base (9406ef7) to head (1590e94).
Report is 24 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #62      +/-   ##
==========================================
+ Coverage   94.85%   94.88%   +0.03%     
==========================================
  Files          15       15              
  Lines        1534     1544      +10     
==========================================
+ Hits         1455     1465      +10     
  Misses         79       79              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[kklein]

Thanks for working on this! :)

[kklein]

I haven't quite grasped yet what the motivation for this attribute is. If the user expects a generator, won't they just be used to querying it until it no longer yields?

[FrancescMartiEscofetQC]

Yes! But I think it may be useful in the case the user wants to show a progress bar or similar, this way it's easier for them to access the number of metalearners to fit instead of having to calculate it manually.

[kklein]

I think I understand what you mean. At the same time this use case is not super clear to me. Shall we simplify and remove it until we witness that there is a need for it?

[FrancescMartiEscofetQC]

I think I may not explain it correctly, in the case we set store_raw_results = False and store_results = False then the fit method finishes "instantly" (it does not wait for fitting the individual metalearners). Then, afaict these are only fitted when the user requests them by iterating over the generator where it may be of use to use this grid_size_ to display some progress bar or similar. If you still think it's not clear lmk and we can discuss it further.

[FrancescMartiEscofetQC]

As discussed, I added some explanation about this in the docstring:
1590e94

[kklein]

LGTM :)

[kklein]

LGTM