bugGNU Octave - Bugs: bug #55052, Memory consumption of figure...


bug #55052: Memory consumption of figure command going up significantly from 4.2 to 4.4

Submitted by:  None
Submitted on:  Mon 19 Nov 2018 05:39:09 AM UTC  
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Performance
Status:  Confirmed Assigned to:  None
Originator Name:  Originator Email:  -email is unavailable-
Open/Closed:  Open Release:  dev
Operating System:  Any

Add a New Comment(Rich Markup)

You are not logged in

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


( Jump to the original submission)

Sat 19 Jan 2019 06:09:37 PM UTC, comment #9:

Another test I did was to switch the graphics toolkit to gnuplot. In that case, each new figure results in only a few tens of kilobytes usage. Presumably this is graphics_properties object.

In any case, it points to the problem being with the OpenGL toolkits rather than our overall graphics code.

I don't like the crazy memory usage, but I don't think this is a blocker. It seems quite unusual to create hundreds of figures in an Octave session. Most of the time I find there are only a few open figures and they are re-used for new plots.

Rik <rik5>
Project Administrator
Sat 19 Jan 2019 04:40:51 PM UTC, comment #8:

With the latest sources (stable or default) the qt graphics toolkit is loaded dynamically. So that means you should see a big jump for the first figure as Octave loads the QtOpenGL and dependent libraries. When _init_qt_ is executed it calls mlock, so Octave won't unload the .oct file and libraries. Even after I tried munlock and calling _shutdown_qt_ and clear all, I was unable to get Octave to unload the _init_qt_.oct file.

Apart from the memory allocated to the shared library, I also see the usage go up with figure creation. I'm looking at the value of RSS reported by ps:

So it is increasing by about 13MB for each new figure and only decreasing by about 2MB, though closing the last figure seems to release more.

Here is what I see with fltk:

It's no surprise that fltk is smaller than qt, but I don't understand what's going on with this case because the size appears to increase when closing figures?!?

John W. Eaton <jwe>
Project Administrator
Fri 18 Jan 2019 09:53:34 PM UTC, comment #7:

Changing the Operating System to Any. Each new figure on Linux is ~7MB on my machine which is way too much. Interestingly, if you close the figures the memory is not reclaimed until Octave actually exits.

Rik <rik5>
Project Administrator
Mon 31 Dec 2018 12:06:07 AM UTC, comment #6:

How bad does it gets if you set graphics_toolkit to gnuplot?
Perhaps it is related to but #55287


Dmitri A. Sergatskov <dasergatskov>
Sun 30 Dec 2018 11:54:49 PM UTC, comment #5:

With Octave-6.0.0, M usage on Linux for just an empty figure handle amounts to ~6 MB. Less than on Windows, but still IMO outrageously much.

(checked using the command in a bash shell:

ps -eo size,pid,user,command --sort -size | awk '{ hr=$1/1024 ; printf("%13.2f Mb ",hr) } { for ( x=4 ; x<=NF ; x++ ) { printf("%s ",$x) } print "" }' |cut -d "" -f2 | cut -d "-" -f1 | grep octave

after each "figure" command in Octave, see below)

Philip Nienhuis <philipnienhuis>
Project Member
Sun 30 Dec 2018 11:32:07 PM UTC, comment #4:

With 6.0.0, just the command "figure" makes RAM usage go up with 37 MB.

Philip Nienhuis <philipnienhuis>
Project Member
Thu 13 Dec 2018 05:37:20 PM UTC, comment #3:

bug #55064 looks related.
Anyway even 35 MB RAM for a graphics handle about just a few data is just ridiculous.

Philip Nienhuis <philipnienhuis>
Project Member
Tue 20 Nov 2018 08:11:24 AM UTC, comment #2:

On Windows it's not so bad, with a 64bit idx 5.0.0 dev cross-build "just" 35 MB per figure :-)

Philip Nienhuis <philipnienhuis>
Project Member
Mon 19 Nov 2018 05:21:08 PM UTC, comment #1:

I can confirm that memory consumption has been going up. I tested on a Linux system using self-compiled binaries.

Results for a new figure

Octave 4.2.1 : 24MB
Octave 4.4.1 : 48MB
Octave 5.0.0 : 48MB

The amount might be larger on Windows, but the trend is the problem.

Rik <rik5>
Project Administrator
Mon 19 Nov 2018 05:39:09 AM UTC, original submission:

Hello all!

Each invocation of the "figure" command in version 4.4.0 requires extra 110 MG of memory while in 4.2.1 it requires about 3-4 MG.




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

Attach Files:

No files currently attached


Depends on the following items: None found

   bug dependencies.


Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)

    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 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-01-18 rik5 Operating SystemMicrosoft Windows => Any
    2018-12-27 rik5 Dependencies- => bugs #55287 is dependent
    2018-11-20 philipnienhuis Release4.4.1 => dev
    2018-11-19 rik5 StatusNone => Confirmed
        Release4.4.0 => 4.4.1
        SummaryMemory consumption of figure command => Memory consumption of figure command going up significantly from 4.2 to 4.4

    Back to the top

    Powered by Savane 3.4