octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #47052] Plotting many lines on a graph is slow


From: Lachlan Andrew
Subject: [Octave-bug-tracker] [bug #47052] Plotting many lines on a graph is slow
Date: Wed, 03 Feb 2016 11:26:40 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0

URL:
  <http://savannah.gnu.org/bugs/?47052>

                 Summary: Plotting many lines on a graph is slow
                 Project: GNU Octave
            Submitted by: lachlan
            Submitted on: Wed 03 Feb 2016 11:26:38 AM GMT
                Category: Plotting
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Performance
                  Status: None
             Assigned to: None
         Originator Name: Lachlan
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: dev
        Operating System: Any

    _______________________________________________________

Details:

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.




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?47052>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]