Wed 23 Nov 2016 10:10:10 PM UTC, comment #10:
This issue is still present in Octave 4.2.0.
When I run the example code from comment #3 (with graphics_toolkit qt) then the plot still takes forever.
|
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].
|
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.
|
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
|
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.
|
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_.
|
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.
|
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));
|
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.
|
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.
|
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?
|