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

 
 

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

Submitter:  Lachlan Andrew <lachlan>
Submitted:  Wed 03 Feb 2016 11:26:38 AM UTC
   
 
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Performance
Status:  Fixed Assigned to:  None
Originator Name:  Lachlan Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 27 Jan 2019 05:39:40 AM UTC, comment #10: 

I came across this bug report again.  Without knowing that it existed, I also came to the conclusion that _go_line_ should be called directly.  That change was made recently


changeset:   26210:da75dfccf14b
user:        Rik <rik@octave.org>
date:        Wed Dec 12 11:25:38 2018 -0800
summary:     __plt__.m: Improve performance by 35% by calling __go_line__ directly.


Rewriting the C++ deserves its own project, or at least something on the patch tracker.

Marking this bug as fixed and closing report.

Rik <rik5>
Group administrator
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>
Group 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>
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>
Group 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>
Group Member
Sat 13 Feb 2016 09:50:54 AM UTC, comment #5: 

Here is a patch ready for feedback.

Before:


octave:1> a = rand (48, 365);
octave:2> tic; for i = 1:100; plot (a'); end; toc
Elapsed time is 87.1696 seconds.
octave:3> tic; for i = 1:100; plot (a); end; toc
Elapsed time is 682.938 seconds.
octave:4>


After:


octave:1> a = rand (48, 365);
octave:2> tic; for i = 1:100; plot (a'); end; toc
Elapsed time is 9.98498 seconds.
octave:3> tic; for i = 1:100; plot (a); end; toc
Elapsed time is 51.0427 seconds.


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>
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>
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>
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>
Group administrator
Wed 03 Feb 2016 11:26:38 AM UTC, original submission:  

On my system,


a = rand (48, 365);
tic; plot (a); toc


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


tic; plot (a'); toc


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>

 

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

Attach Files:
   
   
Comment:
   

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)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-01-27 rik5 StatusIn Progress Fixed
        Assigned tolachlan None
        Open/ClosedOpen Closed
    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.13-3230.
    Corresponding source code