octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #55064] Updating graphics object consumes memo


From: anonymous
Subject: [Octave-bug-tracker] [bug #55064] Updating graphics object consumes memory
Date: Tue, 20 Nov 2018 10:53:25 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:63.0) Gecko/20100101 Firefox/63.0

URL:
  <https://savannah.gnu.org/bugs/?55064>

                 Summary: Updating graphics object consumes memory
                 Project: GNU Octave
            Submitted by: None
            Submitted on: Tue 20 Nov 2018 03:53:23 PM UTC
                Category: Plotting
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Performance
                  Status: None
             Assigned to: None
         Originator Name: Robert F
        Originator Email: address@hidden
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 4.4.1
        Operating System: GNU/Linux

    _______________________________________________________

Details:

I don't think this is the intended behavior of 'set(h,'xdata'...)' and I can't
figure out a way to update a plot, with identically sized 'data' arrays,
without octave searching for more memory with each update. 

Either using the 'set' or even 'delete(h); clear('h'), h=plot3();', when I
update the plot with a new set of data that is exactly the same dimensions,
new memory is reserved. This creates a huge problem where, in the simplified
script I have attached, octave's reserved memory goes from ~200MB to many GB's
very quickly. Is this the intended behavior of 'set' or is there a better way
that can be documented (or maybe I missed?) to update a plot? Regards, Robert.




    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?55064>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]