The examples given in this report seem to execute quickly now.

Closing as fixed.

Is there a particular reason why we don't use a single patch for all scatter points?
The attached patch performs quite fast on my machine with Windows 10 using hg id 12a53552db92. Also the demos for scatter and scatter3 still look correct to me.

One difference is that the scatter points are no longer sorted by value (i.e. the largest value on top) but they are plotted in whatever order they are given in the input. However, it is questionable whether the previous behaviour was correct.

Do we need to distinguish between many and few scatter points?

(file #47878)

There are no visual differences if the one-line fix from comment #5 is used in your code.  Nor are there compatibility differences as that line will work under Matlab as well.  Use the one-line fix for now.

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.

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

patch (x(1:1000), y(1:1000), c(1:1000), 'marker', 'o', 'linestyle', 'none', 'facecolor', 'none')

But I benchmarked it and it is still pretty slow.

   #                Function Attr     Time (s)        Calls
-----------------------------------------------------------
   1                            R        5.491           47
  68                 drawnow             4.467            1
  18             __go_axes__             0.010            1
  66            __go_patch__             0.006            1
  28                     set             0.003            1
  30               __patch__             0.001            1
  45             __isequal__             0.001            2
  53 __patch__>setvertexdata             0.000            1
   2                   patch             0.000            1
  16                    axes             0.000            1
  55                ismember             0.000            2
  54     __patch__>delfields             0.000            2
  20                ancestor             0.000            1
  15                     get             0.000            4
  12                     gca             0.000            1
  44                 isequal             0.000            2
  67             addlistener             0.000            7
   3    __plt_get_axis_arg__             0.000            1
  38                isvector             0.000            4
  52                     isa             0.000            2

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.

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:

octave:1> a = randn (1e4, 2);
octave:2> scatter (a(:,1), a(:,2));
octave:3> c = randi (64, 1e4, 1);
octave:4> scatter (a(:,1), a(:,2), [], c);
octave:5> c = fix(randn (1e4, 1));
octave:6> scatter (a(:,1), a(:,2), [], c);

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

octave:7> c = randn (1e4, 1);
octave:8> scatter (a(:,1), a(:,2), [], c);

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.

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.

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?