Closed jeffjennings closed 9 months ago
I think that it is just keeping a reference to the array, not copying it, since arrays are passed by reference. If I was interpreting the memray results correctly, this understanding was consistent with the total memory used.
Before the Hermitian concat operation had not only doubled the size of the array, but also resulted in a new array to keep track of.
One way to check this would be to create a copy or a throwaway branch and implement an operation in DirtyImager that modifies the values of the self.uu array. Once the routine exits, the modification should be present in the original array that was passed into init.
Yes right and I guess it would require a rewriting of some parts of GridderBase
too. Anyway, just a thought.
My interpretation of how things are working is that GridderBase
already stores/d values by default, and therefore has/d a minimal memory footprint as far as storing the dataset is concerned (performance inherited by DataAverager
).
The old version ofDirtyImager
was different because it had a concat
operation that copied the original data arrays to a new array that contained the Hermitian pairs.
Is your feature request related to a problem or opportunity? Please describe. Memory footprint of
DirtyImager
was reduced in #230 by making the data (u, v, ReV, ImV, weights) properties of the class. These are only used inDirtyImager
by the private function_grid_visibilities
and the functionget_dirty_image
that calls_grid_visibilities
. The memory footprint could be further reduced, significantly for large datasets, by calling_grid_visibilities
whenDirtyImager
is instantiated and storing the gridded data, rather than making the loose data properties that have to be pulled into memory by_grid_visibilities
wheneverget_dirty_image
is called.I don't think the loose data really need to be kept in
DirtyImager
for another reason (since no other routine internal to it uses them), do they? If not, I could implement this.