bugGNU Octave - Bugs: bug #55064, Updating graphics object consumes...

 
 

bug #55064: Updating graphics object consumes memory

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:  Confirmed Assigned to:  None
Originator Name:  Robert F Originator Email:  -email is unavailable-
Open/Closed:  Open Release:  4.4.1
Operating System:  GNU/Linux

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Thu 13 Dec 2018 05:35:33 PM UTC, comment #5:

bug #55052 looks suspiciously related.

Philip Nienhuis <philipnienhuis>
Project Member
Wed 12 Dec 2018 04:38:35 PM UTC, comment #4:

Thanks, just to confirm, the same behavior appears in 4.2.2, and even cla and clf don't get around the issue.

Robert F <robcylon7>
Tue 20 Nov 2018 11:31:37 PM UTC, comment #3:

I have broken the original archive file in to four pieces: 55064.[a-d].tar.lz and uploaded them. To recreate the original file and then unpack it use

Then

Rik <rik5>
Project Administrator
Tue 20 Nov 2018 11:27:12 PM UTC, comment #2:

The Savannah bug tracker has an annoyingly low file limit. I downloaded your test case from Google Drive. I had to modify the paths in solarsystem3.m to point to the data/ directory, but then it ran fine.

There is something wrong. I let it run for a while and memory consumption on the process rose from 2GB to 6GB. After breaking out of the loop with Ctrl-C I closed the figure and deleted all variables, but the Octave process continued to use a bunch of memory.

Marking as confirmed.

Rik <rik5>
Project Administrator
Tue 20 Nov 2018 04:16:04 PM UTC, comment #1:

not quite sure qhy the file didn't upload but
https://drive.google.com/open?id=1G9PNuYKVZmZkVoMQ8XGEFd35vDA4OLjK

Robert F <robcylon7>
Tue 20 Nov 2018 03:53:23 PM UTC, original submission:

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.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #45503:  55064.d.tar.lz added by rik5 (581KiB - application/octet-stream)
file #45502:  55064.c.tar.lz added by rik5 (750KiB - application/octet-stream)
file #45501:  55064.b.tar.lz added by rik5 (750KiB - application/octet-stream)
file #45500:  55064.a.tar.lz added by rik5 (750KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by robcylon7 (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-11-20 rik5 Attached File- => Added 55064.d.tar.lz, #45503
    2018-11-20 rik5 Attached File- => Added 55064.c.tar.lz, #45502
    2018-11-20 rik5 Attached File- => Added 55064.b.tar.lz, #45501
    2018-11-20 rik5 Attached File- => Added 55064.a.tar.lz, #45500
    2018-11-20 rik5 StatusNone => Confirmed

    Back to the top


    Powered by Savane 3.3