bugGNU Octave - Bugs: bug #40663, scatter and scatter3 terribly slow...

 
 

bug #40663: scatter and scatter3 terribly slow with real-valued color vector

Submitted by:  José Luis García Pallero <jgpallero>
Submitted on:  Thu 21 Nov 2013 05:50:43 PM UTC  
 
Category: PlottingSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Performance
Status: ConfirmedAssigned to: None
Originator Name: Open/Closed: Open
Release: devOperating System: GNU/Linux

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Fri 22 Nov 2013 05:14:40 PM UTC, comment #9:

José,

Once you have 64 discrete values it's just a linear transform to change them from the range [0 64] to the old range [c_min c_max].

Rik <rik5>
Project Administrator
Fri 22 Nov 2013 05:12:00 PM UTC, comment #8:

I believe Jordi was the one who benchmarked scatter early on and came up with the policy of accumulating multiple colors under the same patch. We could move everything to a single patch command along the lines of

But I benchmarked it and it is still pretty slow.

Rik <rik5>
Project Administrator
Fri 22 Nov 2013 10:45:54 AM UTC, comment #7:

The suggestion if Rik is a good solution:

c_discrete = fix (rows (colormap) / range (c(:)) * (c + abs (min (c(:)))));

But it has the problem that if after the scatter() I call to colormap() function, the colormap has the range [0 64] instead of the range of the original data

José Luis García Pallero <jgpallero>
Fri 22 Nov 2013 01:34:09 AM UTC, comment #6:

My apologies if this sounds naive, but can't we have a single patch object, and assign a different color to each vertex? This assumes our patch objects interpret this correctly, but eventually it should.

Michael Goffioul <goffioul>
Project Member
Fri 22 Nov 2013 12:38:37 AM UTC, comment #5:

The issue is going to occur whenever you have huge numbers of colors. In this case the scatter script is trying to consolidate and call the patch function the minimum number of times necessary. It does this by finding out which points have the same color and grouping them. The first examples you sent work because the number of colors is small. In the biggest case it is equal to the average size colormap of 64 and the plot is nearly instantaneous.

But with 10,000 unique colors it needs to call the patch function once for each point and that is a lot of overhead. There might be ways to reduce this. One way would be to reduce the colors to the size of the colormap, since that is the largest number that will be displayed anyways. Before calling scatter, for example, you could do

Longer term, patch and _go_patch_ (C++) need to be overhauled. Not only are they slow, but they fail to reproduce the correct coloring behavior as I reported in another bug. Here is some empirical data from the Octave profiler where I used just 1,000 points (which still takes 10 seconds). The problem function is _go_patch_.

Rik <rik5>
Project Administrator
Thu 21 Nov 2013 09:06:02 PM UTC, comment #4:

Ok, I see slow performance with this example, definitely due to the presence of the 4th argument.

These three uses do not appear to me to be any different in performance:

but the following usage is extremely slow (I haven't waited long enough to let it finish yet)

It's not clear to me from the help for scatter what the expected behavior is when the color argument is a vector with the same length as X but consists of non-integral values instead of integer-valued indices.

Mike Miller <mtmiller>
Project Member
Thu 21 Nov 2013 08:27:14 PM UTC, comment #3:

I'm not now at my office, so I can't inform about execution times. I'm calling scatter() in a similar way as:

a = randn(10000,3);
scatter(a(:,1),a(:,2),[],a(:,3));

José Luis García Pallero <jgpallero>
Thu 21 Nov 2013 08:13:16 PM UTC, comment #2:

We do need a test case. But first, some observations. The gnuplot backend will always be slower because the communication is done over pipes, choose fltk for speed. Second, the scatter routines were overhauled in the current development branch and 3.6.4 is not worth comparing for speed. Third, there are breakpoints in the code. Below 100 points a different algorithm is used so it is important to know which regime you are finding slow. Fourth, scatter relies internally on the patch function which has yet to be overhauled for speed. Improving patch() may solve most of the problems.

Rik <rik5>
Project Administrator
Thu 21 Nov 2013 07:50:45 PM UTC, comment #1:

I think more information is needed here, such as an example script that shows what you would call slow performance so others can evaluate it on their systems.

I just did a simple scatter plot with FLTK,

and I don't see any performance issues, plot appears and draws as quickly as the plot function.

Mike Miller <mtmiller>
Project Member
Thu 21 Nov 2013 05:50:43 PM UTC, original submission:

I'm trying to use the scatter and scatter3 functions with vectors containing around ~10000 points and I see that the functions are terribly slow. I've tested the stable 3.6.4 version and the developments sources, and I've used as graphics backend both gnuplot and fltk. These functions in Matlab are fast as the normal plot command.

Any idea about the poor performance in Octave of scatter and scatter3?

José Luis García Pallero <jgpallero>

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by goffioul (Posted a comment)
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by mtmiller (Posted a comment)
  • -unavailable- added by jgpallero (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 21 Nov 2013 09:06:02 PM UTCmtmillerStatusNeed Info=>Confirmed
      Summarystatter and scatter3 terribly slow=>scatter and scatter3 terribly slow with real-valued color vector
    Thu 21 Nov 2013 07:50:45 PM UTCmtmillerItem GroupNone=>Performance
      StatusNone=>Need Info

    Back to the top


    Powered by Savane 3.1-cleanup