Argthtjtr

I create animations for physics classroom demos by simply updating the plot data using a loop. The problem is that the more complicated animations with many handles and/or vertices consumes a lot of memory. I have tried to both delete 'handle' and set ('handle', xdata...) and I see the same issue.

This working example was my best attempt so that I make sure when I 'set' with new xdata, that the size of the new coordinate arrays are exactly the same size as the arrays being replaced, avoiding (so I thought) the need to go search for some new memory real estate that can accommodate the new array. This small example grows to about 5x memory usage for the octave thread from start to finish even though I am just re-'set'ing a single point. How can I do this so that every time I change the handle's data I don't eat more memory? I am using Octave 4.4 Thanks!

clear all;

close all;

figure('position',[50,50,800,600]);



planetx=ones(15000,1);



planety=ones(15000,1);



planetz=ones(15000,1);



N=size(planetx)(1,1)

h=scatter3(planetx(1,:),planety(1,:),planetz(1,:) , 'filled');

hold on;

p1=plot3([planetx(1,1),zeros(1,70)],[planety(1,1),zeros(1,70)], [planety(1,1),zeros(1,70)],'color','k','markersize',3,'*');



title(sprintf('YEAR=%f',2000+i/N*200 ))

axis([-15,15,-15,15,-15,15],'square');

set(gca,'fontsize',20)

axis('manual')

set(gca, 'cameraviewanglemode', 'manual')

view([15,15]);



n1=69;

i=1;



play='y' #input("'y' to replay, any button to close!","s")

while (play=='y');

for i=1:1:N 

    set(h, 'xdata', planetx(i,:) , 'ydata', planety(i,:), 'zdata', planetz(i,:))

    title(sprintf('YEAR=%f',2000+i/N*200 ))



    if (i<(n1+1))

        zer=zeros(1, 70-size(1:i)(1,2));

        set(p1, 'xdata',[planetx(1:i,1)',zer],'ydata',[planety(1:i,1)',zer],'zdata',[planetz(1:i,1)',zer])

    else

        zer=zeros(1, 70-size(i-n1:i)(1,2));

        set(p1, 'xdata', [planetx(i-n1:i,1)',zer],'ydata',[planety(i-n1:i,1)',zer],'zdata',[planetz(i-n1:i,1)',zer])

    endif;

    pause(.001)

endfor

play=input("'y' to replay, any button to close!","s")

endwhile

EDIT: So if instead I use the code

if (i<(n1+1))



    set(p1, 'xdata',[planetx(1:i,1)',zeros(1, 70-size(1:i)(1,2))],'ydata',[planety(1:i,1)',zeros(1, 70-size(1:i)(1,2))],'zdata',[planetz(1:i,1)',zeros(1, 70-size(1:i)(1,2))])

else

    set(p1, 'xdata', [planetx(i-n1:i,1)',zeros(1, 70-size(i-n1:i)(1,2))],'ydata',[planety(i-n1:i,1)',zeros(1, 70-size(i-n1:i)(1,2))],'zdata',[planetz(i-n1:i,1)',zeros(1, 70-size(i-n1:i)(1,2))])

endif;

...I would think there should be no temporary variables being stored except the handle p1 which is never changing it's dimensions. BUT I still see gradual and just as severe memory creep...

I'm assuming you meant to provide a slightly more interesting animation example ... but in any case running this on my octave does not display any noticeable increase in memory usage. Perhaps, as you say, because it's a trivial animation.

However, in general, there's not much you can do for memory optimisation in octave, with the exception of avoiding to create / assign new variables if you can afford to change things in-place, since this avoids the need for allocating new memory to hold the new object. This is also the principle behind assigning index-by-index to a preallocated array in for loops, as opposed to appending an element to the end of an array at each iteration (when you 'append' to an array, you effectively need to allocate space for the now 'larger' array first).

For example, in your example above, instead of calling zeros each time (which allocates a new array in memory) and assigning this new object to 'zer', it may be more efficient to assign the result in-place to each element in the existing 'zer' itself (i.e. zer(:) = zeros(bla bla)). I cannot guarantee this is faster because it depends on how quickly octave destroys the temporary 'zeros' output compared to the unused memory that used to be held by 'zer' before its reallocation ... but it may be something that could make a difference.

The other thing you could try is rely on the fact that octave (like matlab) relies on lazy evaluation. E.g. doing A = B will not allocate new memory for A, until B changes in the meantime; at which point octave 'unlinks' A from B, and allocates space for it at that point to hold the now different array. so if at any point in your animations you find yourself initialising a lot of structures in the same way, you could initialise these with each other, and octave will not allocate extra memory for each component until it needs to. Have a look here if you're interested: https://octave.org/doc/interpreter/Miscellaneous-Techniques.html#Miscellaneous-Techniques

But, honestly though, all this is microoptimisations. Unless you're dealing with huge matrices, I doubt any of this makes a significant difference in terms of memory usage ...

EDIT

Here is some code I tried implementing the above principles (or so I hoped).

% slightly more interesting animation

planetx = 10 * cos(0.1:0.1:1500).';

planety = 10 * sin(0.1:0.1:1500).';

planetz = (planetx + planety);



% ... intermediate code as in question

% [...]



% updated while loop using above concepts

xdata = zeros(70,1); % we will be updating these in place using slices from planetx

ydata = zeros(70,1); % similarly for y and z

zdata = zeros(70,1);



while (play=='y');

  for i=1:1:N 

    set(h, 'xdata', planetx(i,:) , 'ydata', planety(i,:), 'zdata', planetz(i,:))

    title(sprintf('YEAR=%f',2000+i/N*200 ))



    if i < (n1 + 1)

      xdata(1:i, 1) = planetx(1:i, 1);

      ydata(1:i, 1) = planety(1:i, 1);

      zdata(1:i, 1) = planetz(1:i, 1);

      set(p1, 'xdata', xdata, 'ydata', ydata, 'zdata', zdata)

    else

      xdata(1 : n1+1, 1) = planetx(i-n1:i, 1);

      ydata(1 : n1+1, 1) = planety(i-n1:i, 1);

      zdata(1 : n1+1, 1) = planetz(i-n1:i, 1);        

      set(p1, 'xdatasource', 'xdata', 'ydatasource', 'ydata', 'zdatasource', 'zdata')

    endif;

    refreshdata;

    pause(0.001)

  endfor

  play=input("'y' to replay, any button to close!","s")

endwhile

This replaced unnecessary calls resulting in temporary allocations (e.g. zeros and size calls), uses updating of preallocated arrays (e.g. xdata) instead of overwriting, and uses xdatasource, which I was hoping would be implemented as a pointer rather than as a reassignment under the hood.

Turns out it's worse memory-wise, if anything. So yeah, worth letting the octave team know. :p