bugGNU Octave - Bugs: bug #55908, Closing plots much slower in...


bug #55908: Closing plots much slower in Octave 5.1.0

Submitted by:  None
Submitted on:  Wed 13 Mar 2019 09:22:10 AM UTC  
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Ready For Test Assigned to:  None
Originator Name:  Originator Email:  -email is unavailable-
Open/Closed:  Open Release:  5.1.0
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)

Fri 22 Mar 2019 07:39:28 PM UTC, comment #12:

I noticed the gcbo failure but didn't think to look at this bug report. Bisecting showed

While trying to find the problem, I also found that I could duplicate the error with

That helped to significantly speed up bisecting.

I also tried looking at the parents of the graphics object that gcbo returns in the test but unlike what Rik notes in comment #10, calling get on the first parent causes Octave to crash with a segfault.

To see what the parent objects were, I changed the test to

Here is the output I see:

It looks like a graphics handle is being deleted but not removed from the list of handles? Maybe tracing the handles that are created and deleted for this series of tests with and without the patch could help with debugging? Limit the tracing to objects that could be returned by gcbo?

John W. Eaton <jwe>
Project Administrator
Wed 20 Mar 2019 12:20:11 PM UTC, comment #11:

I tested the patch and it works well for now.

The time for closing the example figure is now < 0.1 s.


Roland Baudin <roland65>
Mon 18 Mar 2019 04:32:36 AM UTC, comment #10:

This is very strange. I changed the BIST test in gcbo to

and then ran 'make check'. It does stop at the keyboard statement and I can check the handle which is valid, according to ishghandle(). The "type" of the handle is "line", but if I look at the properties I see it contains one called "basevalue". This is not a property that a default line object has. A stem, bar, or area graph might have a basevalue property which may mean it is left over from one of those BIST tests.

If I check the root object, I see that the "callbackobject" property does contain this handle. However, gcbf returns [] so there is no active figure. I wonder if something is going wrong with deleting/closing figures and the root object is not being updated properly.

If I follow the hierarchy up. The parent of the "line" object is an axes object which is valid. The parent of the axes object is the figure object 1. And the figure is not valid, so how the axes exists is unknown.

Rik <rik5>
Project Administrator
Sun 17 Mar 2019 04:47:30 PM UTC, comment #9:

I just re-run "make check" on the buildbot console and it is
still failing at those two. Yet running those tests interactively passes.


Dmitri A. Sergatskov <dasergatskov>
Sun 17 Mar 2019 01:10:12 PM UTC, comment #8:

Since this change the tests for gcbo and movegui are failing on the buildbots. They are not failing if I run the tests individually.
To be honest I don't understand what is going on. Are the tests in the test suite run differently from what is done in the GUI or CLI?

Markus Mützel <mmuetzel>
Project Member
Sun 17 Mar 2019 09:41:36 AM UTC, comment #7:

I run the dump_plot_demos script and apart from some unrelated issues (probably bug #55895) the results look good. So I pushed the patch here:

Marking as ready for test.

Markus Mützel <mmuetzel>
Project Member
Sat 16 Mar 2019 09:30:20 PM UTC, comment #6:

Thanks for bisecting.
The problem seems to be that calling the remove_children callbacks is slow. But it isn't necessary to call these functions if the figure is going to be closed anyway (I think).
The attached patch skips executing the remove_children callbacks in that case.
The time for closing the figure from the example in comment #0 reduces from just above 10 seconds to about 10 milliseconds for me.
Further testing is still necessary.

(file #46561)

Markus Mützel <mmuetzel>
Project Member
Fri 15 Mar 2019 09:39:40 AM UTC, comment #5:

Hi there, I am the author of the bug report (don't know why it's tagged "Anonymous" ?).

More information about the bug: I have a simulation with several contour plots (with a lot of graphic elements) and 3D mesh.

The slowness problem is more apparent when closing the contour plots that have a lot of graphic elements, thus my example.

Roland Baudin <roland65>
Wed 13 Mar 2019 11:35:40 PM UTC, comment #4:

Sorry, trying again:

I bisected using the original example and the cset that triggers most of the slowdown for me is

Ccing markus to see if he understands what is going on.

Pantxo Diribarne <pantxo>
Project Member
Wed 13 Mar 2019 11:34:21 PM UTC, comment #3:

I bisected using the original example and the cset that triggers most of the slowdown for me is

Pantxo Diribarne <pantxo>
Project Member
Wed 13 Mar 2019 08:38:17 PM UTC, comment #2:

I think that a small delay may have been introduced in the deletion of graphics objects to work around cross-thread issues between the GUI and the main interpreter thread. But that might be completely off.

In any case, this happens for both 2-D and 3-D plots so I have changed the Summary to reflect that.

For the 2-D case, I used

For version 4.4.1 this takes 60 milliseconds, but 340 milliseconds with 5.1.0. That is approximately a factor of 5 slowdown. That isn't as bad as the reporter's 60X slowdown for a 3-D scene, but still bad.

Rik <rik5>
Project Administrator
Wed 13 Mar 2019 01:29:26 PM UTC, comment #1:

Confirmed. This doesn't on the toolkit the toolkit (both gnuplot and qt take ~28s closing the figure on my system) but it is rather related to the deletion of the large amount of graphics objects.

Pantxo Diribarne <pantxo>
Project Member
Wed 13 Mar 2019 09:22:10 AM UTC, original submission:

For 2D plots, closing a figure takes a very long time in Octave 5.1.0, while it only takes a fraction of second in Octave 4.4.1.

Here is a test, to reproduce the issue:

1. Plot a (rather complex) 2D figure with contours and labels:

x = [-1 : 0.05 : 10];
y = [-1 : 0.05 : 10];
z = sin(x') * cos(y);

[c, h] = contour(x, y, z, [-1 : 0.03 : 1]);
clabel(c, h, 'FontSize', 15, 'Color', 'k');

2. Close the figure:
tic; close(1); toc

Here are the timings for close():

Octave 4.4.1

Windows 7 64 bits => 0.1 s
Ubuntu Linux 18.04 64 bits => 0.2 s

Octave 5.1.0

Windows 7 64 bits => 14 s
Ubuntu Linux 18.04 64 bits => 12 s

As you see, closing the figure is nearly 100 times slower in Octave 5.1.0.

I also noticed that plotting the figure is ~20% slower in Octave 5.1.0.

Closing a simple 1D plot, doesn't have the issue, as far I can tell...



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

Attach Files:

Attached Files
file #46561:  bug55908_delete_from_groot.patch added by mmuetzel (11KiB - 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 jwe (Posted a comment)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by mmuetzel (Updated the item)
  • -email is unavailable- added by roland65 (Posted a comment)
  • -email is unavailable- added by pantxo
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by pantxo (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-03-17 mmuetzel StatusPatch Submitted => Ready For Test
    2019-03-16 mmuetzel StatusConfirmed => Patch Submitted
    2019-03-16 mmuetzel Attached File- => Added bug55908_delete_from_groot.patch, #46561
    2019-03-13 pantxo Carbon-Copy- => Added mmuetzel
    2019-03-13 rik5 SummaryClosing 2D plots much slower in Octave 5.1.0 => Closing plots much slower in Octave 5.1.0
    2019-03-13 pantxo StatusNone => Confirmed

    Back to the top

    Powered by Savane 3.4