Why does a griddedInterpolant use twice as much memory as the array of values that it's interpolating between?

Let V be the n-by-n array of values that the griddedInterpolant is interpolating between, and let X and Y be the ndgrid-format arrays that represent the grid of points corresponding to the locations that the values V are measured at.

I would expect one of two relationships between the size of the array V and the size of the griddedInterpolant object. Either,

1. V could occupy roughly the same amount of memory as the griddedInterpolant object (since the Method, ExtrapolationMethod, and GridVectors properties of this object should occupy negligible amounts of memory compared to the Values property).
2. V could occupy roughly 1/3 the amount of memory as the griddedInterpolant object if, for some reason, the griddedInterpolant can make evaluations more quickly if X and Y are always (in the background) stored in their full ndgrid format rather than in their grid vector format.

However, running this script for sufficiently large n reveals that V typically uses half the amount of memory required by the corresponding griddedInterpolant. Does anyone know why this is?

EDIT: Interestingly, this is true for any method of interpolation, and does not seem to be specific to interpolation methods that would require the storage of interpolation coefficients, such as 'cubic'.

clear; close all;

method = 'nearest';
n = 1000;

x = 1:n;
y = 1:n;
[X,Y] = ndgrid(x,y);
V = rand(n,n);

gi = griddedInterpolant({x,y},V,method);
gi2 = griddedInterpolant(X,Y,V,method);
gi3 = griddedInterpolant(V,method);

whos

  Name           Size                 Bytes  Class                 Attributes

  V           1000x1000             8000000  double                          
  X           1000x1000             8000000  double                          
  Y           1000x1000             8000000  double                          
  gi             1x1               16016244  griddedInterpolant              
  gi2            1x1               16016244  griddedInterpolant              
  gi3            1x1               16016244  griddedInterpolant              
  method         1x7                     14  char                            
  n              1x1                      8  double                          
  x              1x1000                8000  double                          
  y              1x1000                8000  double                          

Answer 1

[Matt J]

I suspect that griddedInterpolant does not really consume twice what V consumes. I think it is just a quirk of whos(). Remember that whos() doesn't really track well which Matlab variables share data, so it doesn't provide as reliable a tally of consumed memory as the memory command, which my test below uses:

method = 'linear';
n = 60;
x = 1:n;
V=rand(n,n,n,n);

whos V

memBefore = memory().MemUsedMATLAB;

 gi = griddedInterpolant({x,x,x,x},V,method);

 clear V

memAfter = memory().MemUsedMATLAB;

whos gi


memDifference=memAfter - memBefore

The output of this on my computer is,

Name Size Bytes Class Attributes

V 60x60x60x60 103680000 double

Name Size Bytes Class Attributes

gi 1x1 207362368 griddedInterpolant

memDifference =

0

Notice that the amount of additional memory used after gi is created (and V cleared) is zero. How is that possible if V is 100 MB and gi is truly 200 MB (as reported by whos)? Shouldn't the difference be 100 MB?

[Alex Ogren]

Thanks Matt,

I'll take a look at this a bit later to run myself and experiment (and then likely accept your answer at that point) - just have to go get some exercise first.

[Alex Ogren]

Thanks for the answer, Matt. So it seems that the griddedInterpolant is approximately the size of whatever value array (V) it is based on, and that the griddedInterpolant will try by default to not create a new copy of V.

It's interesting that if we don't unshare V from the copy stored in gi, then the memory difference is zero, suggesting that gi doesn't take any memory. This makes it seem like griddedInterpolant() does (nearly?) nothing (no change in used memory seems to imply it is not generating/storing new information), which is odd, considering how much speed-up can be achieved by re-using a griddedInterpolant object instead of calling interpn() repeatedly. Maybe it is just re-organizing the way the memory is stored (somehow?) to make it more efficient for repeated interpolation?

[Matt J]

Well, if you look at interpn.m, I don't think it is surprising why griddedInterpolant is faster. First of all, interpn is just an Mcoded wrapper for griddedInterpolant and secondly, it is doing lots of set-up and error checking on top of the interpolation work, and it is doing it in Mcode, rather than as a binary.

[Alex Ogren]

That makes sense. I guess I am less confused about why griddedInterpolant would be faster than interpn, and more interested in the fact that the griddedInterpolant seems to take literally zero memory (if it is allowed to share memory with V). I would have thought that it would at least use some memory (even if the memory is negligible in comparison to V) to store some information that would be useful for quick interpolation later.

[Matt J]

I think the memory() command has its accuracy limits as well. It doesn't seem to pick up really small stuff, e.g.,

clearvars

mem_Before = memory().MemUsedMATLAB;

    x = 1:60;

mem_After = memory().MemUsedMATLAB;


Consumed = mem_After - mem_Before,

Consumed =

0