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:

 69140  ## before qt graphics is loaded
139156  ## after figure (1)
152580  ## after figure (2)
165880  ## after figure (3)
163992  ## after close (3)
161624  ## after close (2)
157900  ## after close (1)

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:

 67296  ## before fltk graphics is loaded
100560  ## after figure (1)
101008  ## after figure (2)
101272  ## after figure (3)
101536  ## after close (3)
102692  ## after close (2)
102692  ## after close (1)

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)

## Before "figure" command:
[philip@DeskPRN ~]$ 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
       161.83 Mb /usr/local/libexec/octave/6.0.0/exec/x86_64
         0.57 Mb octave

## After opening 3 figure handles:

[philip@DeskPRN ~]$ 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
       180.06 Mb /usr/local/libexec/octave/6.0.0/exec/x86_64
         0.57 Mb octave
[philip@DeskPRN ~]$

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.5