bugGNU Octave - Bugs: bug #47052, Plotting many lines on a graph is...


bug #47052: Plotting many lines on a graph is slow

Submitted by:  Lachlan Andrew <lachlan>
Submitted on:  Wed 03 Feb 2016 11:26:38 AM UTC  
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Performance
Status:  In Progress Assigned to:  Lachlan Andrew <lachlan>
Originator Name:  Lachlan 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 20 Feb 2016 02:46:40 PM UTC, comment #9:

Probably best to wait a bit. For 4.2 I mean to have Octave move to compatibility with Matlab with respct to 'hold all' and this will simplify _next_line_style_.m.

Rik <rik5>
Project Administrator
Sat 20 Feb 2016 09:01:38 AM UTC, comment #8:

I'm currently in the process of writing _next_line_style_ in C++, and that will also require _pltopt_ to be translated to C++.

Since this is becoming rather a large patch, and Rik was flagging a major rewrite, I'm not sure if I should go ahead. My current patch meets my needs.

If there is to be a major rewrite, some of the things I would suggest are:

- Each class like 'line' could have static defaults, with only those that are overridden being initialized for each object.

- It may be faster to have named constants instead of strings for many of the properties. It would be just as slow when accessed from .m files, but faster from C++.

- It may help to avoid rendering partial figures until they are fully drawn.

- Primitives like _next_line_style_, line and patch should probably be in C++.

Lachlan Andrew <lachlan>In charge of this item.
Mon 15 Feb 2016 11:50:07 PM UTC, comment #7:

I think the entire topic of slow graphics belongs on the Octave Projects page. If there are specific slowdowns that can be addressed with a change to one file then they can get their own bug report. But otherwise I think a coordinated approach touching many files will be necessary.

Rik <rik5>
Project Administrator
Mon 15 Feb 2016 09:35:10 PM UTC, comment #6:

Slightly OT, but Octave is significantly, if not a magnitude or more slower than Matlab when drawing series of patches and esp. drawing grids with surf, mesh and similar functions.

I can dig up some example grids + code to illustrate this.

Philip Nienhuis <philipnienhuis>
Project Member
Sat 13 Feb 2016 09:50:54 AM UTC, comment #5:

Here is a patch ready for feedback.



The optimizations are:
1. Call _go_line_ directly instead of calling line.m many times. (This is in bug_plot2vm.cset -- all other changes are in bug_47052_v1.cset)
2. make _go_line_ accept a matrix consisting of many lines, instead of a single line
3. Instead of creating a new line from scratch each time, clone the first line and change its y properties. (This seems to make the most difference, but I can't see why.)

Things still to do include:
- Calculate line style and line marker (_next_linestyle_ into C++); handle colours with "hold all"
- Set xsource correctely for each line

Questions I have are:
- Is there an obvious flaw in doing this?
- Is there a better way of doing this?
- Is the an underlying reason for the slowness that should be fixed instead of worked around?
- Once this is finished, should it also be done for primitives like surf?

(file #36326)

Lachlan Andrew <lachlan>In charge of this item.
Wed 10 Feb 2016 01:01:09 PM UTC, comment #4:

Thanks for looking at the patch, Dan.

The patch eliminates the per-line processing of line.m which essentially just does input validation and then calls _go_line_. On my system, the patch improves the speed from about 9.7 seconds to about 5.7. I agree that there is still lots of room for improvement, which is why I didn't mark this as "Patch submitted".

I'm not sure about the memory management. I'll look out for that when I next look at this code.

Lachlan Andrew <lachlan>In charge of this item.
Wed 10 Feb 2016 07:55:58 AM UTC, comment #3:

I've confirmed relative behavior similar to what you are describing. I suspect that the slowness comes about because of inefficiency in the figure properties. Transposing results in many more individual lines in one case and those lines probably need to be entered into the figure's children, all properties initialized, etc.

Your changes sound reasonable, but at the same time don't sound like they would be the source of such slowness. I wonder how memory management is done. Is it efficient speed-wise? Space-wise? Etc.

Dan Sebald <sebald>
Thu 04 Feb 2016 12:15:05 PM UTC, comment #2:

Oops. I'm trying again to upload the patch.

(file #36247)

Lachlan Andrew <lachlan>In charge of this item.
Wed 03 Feb 2016 10:01:33 PM UTC, comment #1:

Is there a patch that failed to get uploaded? It is mentioned in the text.

Rik <rik5>
Project Administrator
Wed 03 Feb 2016 11:26:38 AM UTC, original submission:

On my system,

yields about 9.7 seconds, whereas plotting the same amount of data with fewer rows

takes less than a second.

The low-hanging fruit (about 40% of the time) is taken in the attached patch, which calls _go_plot_ directly instead of incurring the overhead of calling line.

Most of the rest of the time seems to be taken up by gh_manager::make_graphics_handle (I suspect it is because each property is quite "heavy"), and by set_[xyz]data. I hope to write a patch to avoid repeatedly calculating the x limits for each line, and only update the axis y limits once instead of once for each line, but it is looking like that will require a lot of changes.

To speed up make_graphics_handle, I'm toying with the idea of having a "default" object of each property for each object (like a default "line":"marker"), and the graphics objects only instantiate their own properties if a non-default value is assigned. Does that sound like a suitable approach?

The other thing I would like to do is replace the string labels for properties by an enumeration. I realise that the .m files will have to stick with string labels, but all the string comparisons seem wasteful. Do people have thoughts on that?

Rik said that the OpenGL graphics needs an overhaul, but I don't think this is toolkit-specific. I first noticed it using gnuplot, and now see it using FLTK. Also, the actual rendering is quite fast.

Lachlan Andrew <lachlan>In charge of this item.


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

Attach Files:

Attached Files
file #36326:  bug_47052_v1.cset added by lachlan (13KiB - application/octet-stream)
file #36247:  bug_plot2vm.cset added by lachlan (2KiB - 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 johasixt
  • -email is unavailable- added by philipnienhuis
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by lachlan (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 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-03-29 johasixt Carbon-Copy- => Added johasixt
    2016-04-14 lachlan StatusPatch Submitted => In Progress
    2016-02-15 philipnienhuis Carbon-Copy- => Added philipnienhuis
    2016-02-13 lachlan Attached File- => Added bug_47052_v1.cset, #36326
        StatusNone => Patch Submitted
        Assigned toNone => lachlan
    2016-02-04 lachlan Attached File- => Added bug_plot2vm.cset, #36247

    Back to the top

    Powered by Savane 3.3